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FOREWARD 


The  US  Army  Research  Institute  is  developing  a  research 
simulation  designed  to  play  the  command  and  control  (C^)  tasks 
attending  armor  platoon  exercises  such  as  Movement  to  Contact 
(STX  E,  FC  17-15-1),  Hasty  Attack  (STX  F,  FC  17-15-1),  and  Defend  a 
Battle  Position  (Task  3-IV-3-7  within  the  tank  platoon  mission 
"Defend") .  This  simulation,  called  Platoon-Level  Battlefield 
Simulation  (PLBS) ,  builds  on  previous  experience  with  a  first 
prototype  simulation  called  SIMCAT  (Simulation  in  Combined  Arms 
Training) .  PLBS  is  being  designed  to  upgrade  SIMCAT  capabilities, 
capitalizing  on  lessons  learned  from  research  with  the  earlier 
system.  PLBS  will  be  microcomputer  controlled,  will  have  a 
separate  player  position  for  the  platoon  leader,  platoon  sergeant, 
and  two  tank  commanders,  and  will  have  a  free-play  OPFOR  station. 
Driving  and  gunnery  will  be  under  the  control  of  simulated  crewmen 
who  are  activated  by  voice  commands  or  the  control  of  a  live  second 
player  at  the  station.  A  full  360°  terrain  base  will  be 
accomplished  using  a  map  display  without  grid  lines.  Indirect 
fire,  smoke,  and  concealed  and  artillery  delivered  mines  will  be 
available  to  both  the  friendly  force  and  the  OPFOR. 

This  report  presents  the  functional  requirements  to  be  met  in 
the  development  of  the  PLBS.  It  outlines,  in  detail,  requirements 
for  simulation  control  and  development,  terrain,  movement  of 
simulated  vehicles,  detection  and  identification,  engagement, 
indirect  fire,  communication,  and  post-simulation  feedback  to 
soldiers  being  trained  on  the  system. 

This  effort  is  part  of  the  Fort  Knox  Field  Unit's  research 
program  to  apply  new  training  technology  to  Armor  skills  training 
needs.  The  Field  Unit's  overall  mission  is  to  improve  methodology 
basic  to  the  derivation  of  Armor  training  and  evaluation 
requirements  and  procedures,  individual  and  collective  training  in 
Armor  schoolds  and  operational  units,  and  systems  for  integration 
and  managing  Armor  training.  A  Memorandum  of  Agreement  covering 
the  application  of  training  technology  to  Armor  skills  training  was 
signed  by  TRADOC,  USAARMC,  and  ARI  on  4  Nov  83.  Plans  for  the 
development  of  PLBS  have  been  briefed  to  the  DCG,  USAARMC,  and  the 
CG,  TRADOC  for  use  in  the  MOS  19K  Basic  Noncommissioned  Officer 
course.  A  similar  effort  is  being  coordinated  with  the  Armor 
School  for  the  Armor  Officer  Basic  and  Advanced  courses.  Plans 
have  been  made  to  pilot  PLBS  technology  with  the  South  Carolina 
National  Guard. 
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PLATOON-LEVEL  BATTLEFIELD  SIMULATION  FUNCTIONAL  REQUIREMENTS 


INTRODUCTION 

The  purpose  of  this  paper  is  to  document  the  functional 
requirements  for  the  Platoon-Level  Battlefield  Simulation  (PLBS) 
system  which  will  be  used  to  conduct  research  on  training  command, 
control,  and  communications  (C^)  skills  among  the  four  leaders  of  a 
tank  or  other  vehicle  platoon  (i.e.,  the  platoon  leader,  the 
platoon  sergeant,  and  the  two  wingmen) . 

The  first  step  in  the  development  of  a  battle  simulation  is  to 
define  "what  the  system  should  do”,  or  in  the  context  of  this 
document,  to  determine  its  functional  requirements.  PLBS  must 
satisfy  a  multitude  of  vastly  different  functional  requirements. 

To  define  these,  some  form  of  classification  is  required  so  that 
they  can  be  organized  and  comprehensible.  The  functional 
requirements  that  have  been  prepared  for  PLBS  are  defined  and 
recorded  in  this  document  and  are  organized  into  the  following 
sections : 

Initialization  —  These  functional  requirements  involve  the 
system  processes  necessary  to  begin  a  PLBS  simulation,  e.g., 
identification  of  scenario  conditions,  speech  enrollments, 
and  definition  of  simulation  variables. 

Terrain  —  These  functional  requirements  involve  providing 
each  PLBS  position  with  knowledge  about  the  terrain  in  which 
he  is  operating,  or,  in  the  case  of  the  Controller/Trainer, 
the  terrain  within  which  both  the  OPFOR  and  friendly  forces 
are  operating.  These  functional  requirements  are  defined  in 
terms  of  terrain  characteristics,  elevation,  effects,  and  the 
perception  requirements  for  each  PLBS  position. 

Movement  —  The  process  and  representation  requirements  for 
movement  are  defined  as  they  relate  to  the  object  that  is 
moving,  the  rate  of  movement,  the  control  of  movement,  and 
the  perception  of  movement. 

This  document  contains  the  functional  requirements  for  PLBS  (Platoon-Level 
Battlefield  Simulation),  a  battle  simulation  being  developed  by  Perceptronics, 
Inc.,  for  the  US  Army  Research  Institute  (ARI).  PLBS  is  an  upgraded  version 
of  SIMCAT  (Simulation  in  Combined  Arms  Training) .  Most  of  the  functional 
requirements  for  PLBS  are  identical  to  those  originally  developed  by  Human 
Resources  Research  Organization  (HumRRO)  for  SIMCAT.  The  structure  of  this 
document,  the  system  architecture,  and  most  ot  the  functional  requirements 
appeared  originally  in  HumRRO  Professional  Paper  2-84,  Specifying  Battle 
simulation  Requirement:  A  Model  and  Case  History,  authored  by  David  L. 
Hannaman .  Wording  from  the  Hannaman  paper  appears  throughout  this  report. 
Since  separate  citations  for  each  instance  would  be  combersome,  this  footnote 
has  been  included  to  apprise  the  reader  of  the  origins  of  the  PLBS  functional 
requirements . 
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Detection/Identification  --  This  category  of  functional 
requirements  concerns  the  relevant  objects,  events,  and 
conditions  of  the  simulation  environment  that  may  be  detected 
and  possibly  identified  by  each  participant  in  a  PLBS 
simulation . 

Engagement  —  The  purpose  of  the  functional  requirements  for 
engagement  is  to  resolve  all  encounters  between  the  military 
weapon  systems  being  simulated  in  a  scenario.  An  encounter, 
in  this  context,  is  defined  as  the  firing  of  one  or  more 
OPFOR  or  friendly  force  weapon  systems  and  the  effect,  if 
any,  on  the  engaged  target  (s). 

Indirect  Fire  —  Dedicated  indirect  fire  support  will  be 
provided  to  each  of  the  opposing  forces  (friendly  and  enemy) 
in  all  PLBS  scenarios.  To  satisfy  this  requirement,  PLBS 
must  provide  a  means  for  requesting  indirect  fire,  impacting 
indirect  fires,  and  representing  the  effects  to  appropriate 
PLBS  positions.  The  representation  and  process  requirements 
necessary  to  satisfy  each  of  these  are  discussed  in  detail. 

Communication  --  The  communication  functional  requirements 
are  specified  in  terms  of  a  verbal  communication  capability, 
hand  and  arm  signal  capability,  and  special  message 
capability . 

Resources  Audit  —  These  functional  requirements  dictate  that 
PLBS  maintain  an  audit  of  all  friendly  force  munitions  and 
fuel  expended  by  each  weapon  system  and  vehicle  simulated  in 
a  scenario.  Given  a  specified  allocation  of  fuel  or 
munitions,  PLBS  must  audit  the  expenditures  of  these 
resources  as  they  occur  and  prevent  further  expenditures  once 
a  resource  has  been  exhausted.  PLBS  must  also  allow  for  the 
resupply  of  munitions  and  fuel  during  a  simulation  run. 

Time  —  These  functional  requirements  dictate  that  PLBS  be 
sensitive  to  and  represent  two  different  types  of  time: 
simulation  time  and  real  time.  Each  of  these  types  of  time 
will  be  discussed  and  information  on  the  functional 
requirements  regarding  simulation  time  will  follow. 

Post-Simulation  --  These  functional  requirements  specify  the 
PLBS  processes  necessary  to  support  Controller/Trainer 
responsibilities  associated  with  providing  feedback  to  the 
vehicle  commanders.  Post-simulation  functional  requirements 
are  divided  into  three  categories:  visual  playback,  audio  or 
communication  playback,  and  hard  copy  outputs. 

Status  and  Informational  Displays  --  These  functional 
requirements  specify  content  requirements  for  the  PLBS  status 
and  informational  displays  necessary  for  each  of  the 
participants . 
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Environmental  —  This  section  describes  the  physical 
requirements  for  the  environment  of  PLBS.  Environmental 
requirements,  as  discussed  in  this  section,  apply  only  to  the 
physical  makeup  of  each  workstation. 

To  understand  the  functional  requirements  discussed  in  the 
remaining  sections  of  this  document,  a  general  understanding  of  the 
PLBS  configuration  is  necessary. 

The  PLBS  hardware  architecture  consists  of  six  (6)  computer 
workstations  connected  through  a  local  area  network.  Four  (4)  of 
the  workstations  are  configured  identically  and  serve  as  vehicle 
commander  stations.  One  workstation  is  the  Controller/Trainer 
station,  and  the  last  workstation  is  the  OPFOR  Controller 
workstation.  All  of  the  workstations  consist  of  an  IBM  PC  AT 
configured  with  an  80286  microprocessor,  an  80287  math 
co-processor,  3MB  of  random  access  memory  (RAM),  a  1.2MB  floppy 
diskette  drive,  an  20MB  hard  disk  drive,  a  graphics  subsystem,  and 
various  input/output  (I/O)  devices.  The  graphics  subsystem  at  each 
workstation  consists  of  a  graphics  board  set,  a  video  disc  player, 
and  a  color  monitor.  The  I/O  devices  at  each  of  the  vehicle 
commander  stations  consist  of  two  joystick  type  devices  (one  for 
driving  the  vehicle  and  one  for  controlling  the  turret),  one  keypad 
device,  and  a  voice  recognition  and  playback  device.  The  I/O 
devices  at  the  Controller/Trainer  station  are  a  monochrome  monitor, 
a  mouse  pointing  device  and  a  high-speed  dot  matrix  printer.  At 
the  OPFOR  Controller  station,  a  monochrome  monitor,  a  joystick  type 
device  (used  as  a  pointing  device  and  to  control  vehicle  movement) 
and  a  keypad  are  the  I/O  devices.  PLBS  includes,  independent  of 
the  workstations  themselves,  a  radio  communications  system  for 
voice  communication  between  the  PLBS  participants. 

The  PLBS  system  will  allow  for  simulation  play  in  two  modes; 

One  Player  Mode  and  Two  Player  Mode.  The  One  Player  Mode  will 
consist  of  six  (6)  human  interactors;  a  Controller/Trainer,  an 
OPFOR  Controller  and  four  vehicle  commanders  each  at  separate 
stations.  The  crew  members  (drivers,  loaders,  and  gunners)  of  the 
vehicle  commander  controlled  vehicles  will  be  simulated  by  the  PLBS 
system.  In  the  Two  Player  Mode,  each  of  the  vehicle  commander 
stations  will  be  augmented  by  a  second  human  crew  member;  a 
driver/gunner.  This  driver/gunner  will  provide  the  necessary 
interface  between  the  vehicle  commander  and  the  simulation  to 
control  vehicle  movement  (direction  and  speed)  and  to  pass  along 
gunnery  commands  (when  the  system  is  not  in  voice  recognition 
mode)  . 

The  Controller/Trainer  will  be  responsible  for  controlling  the 
simulation  and  providing  guidance  and  feedback  to  the  vehicle 
commanders.  The  OPFOR  Controller,  in  cooperation  with  the 
Controller/Trainer,  will  present  the  vehicle  commanders  with  an 
active  opposing  force  and/or  additional  members  of  a  higher  echelon 
unit.  The  four  vehicle  commanders  are  the  platoon  members  for  whom 
training  is  intended;  both  in  the  one  and  two  player  modes.  PLBS 
will  allow  the  vehicle  commanders  to  command  either  a  simulated 
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tank  or  personnel  carrier.  The  OPFOR  Controller  will  control  the 
actions  of  up  to  ten  (10)  entities  (enemy  and/or  additional 
friendly  forces) .  The  entities  which  can  be  controlled  at  the 
OPFOR  station  are:  enemy  tanks,  friendly  and  enemy  personnel 
carriers,  friendly  and  enemy  trucks,  friendly  and  enemy 
helicopters,  and  enemy  man-packed  saggers. 

Throughout  this  document,  the  Controller/Trainer  station 
and/or  the  individual  operating  the  Controller/Trainer  station  will 
be  referred  to  as  the  "Controller."  Similarly,  the  OPFOR  station 
and/or  the  individual  operating  the  OPFOR  station  will  be  referred 
to  as  the  "OPFOR"  and  the  Friendly  Player  Station  (vehicle 
commander  station)  and/or  the  individual  operating  the  Friendly 
Player  Station  (the  person  being  trained  on  the  system)  will  be 
referred  to  as  the  "TC." 

For  the  purposes  of  this  document  the  term  "entity"  shall 
refer  to  one  of  the  following  vehicles  and/or  weapon  systems  which 
will  be  simulated  in  PLBS: 

TC  Controlled  Enties: 

Friendly  force  tank  with  a  main  gun  and  a  coaxial 
machinegun  (discussed  in  terms  of  an  Ml  Abrams) . 

Friendly  force  personnel  carrier  with  a  TOW  and  a  chain 
gun  (discussed  in  terms  of  an  M2/3  Bradley) . 

OPFOR  Controlled  Entities: 

Friendly  and  enemy  force  tank  with  a  main  gun  (enemy  force 
tank  is  discussed  in  terms  of  a  T72) . 

Friendly  force  personnel  carrier  with  a  TOW  and  a  chain 
gun . 

Enemy  force  personnel  carrier  with  a  Sagger  and  a  main  gun. 
Friendly  force  helicopters  with  a  TOW  and  a  chain  gun. 

Enemy  force  helicopters  with  a  sagger  and  a  chain  gun. 
Enemy  force  man-packed-sagger. 

Friendly  and  enemy  force  trucks  with  no  weapon  systems. 

The  remaining  sections  of  this  document  define  the  functional 
requirements  for  the  PLBS  system. 

INITIALIZATION 

System  initialization  is  the  process  by  which  the  PLBS  sytem 
is  prepared  for  a  simulation  run.  In  addition  to  system 


preparations,  and  to  allow  maximum  flexibility  for  research  and 
uses  of  PLBS ,  several  simulation  data  elements  shall  also  be 
accessable  at  or  before  simulation  initialization.  Those  processes 
which  are  required  at  int ialization  and  those  which  are  optional 
together  fall  into  the  following  four  catagories : 

Initial  Conditions. 

Modifiable  Constants. 

Databases . 

Voice  Enrollment. 

Initial  Condition 

The  Controller  shall  be  provided  with  a  means  by  which  he  may 
quickly  and  easily  specify  the  initial  or  starting  conditions  of  a 
simulation  run.  Those  data  elements  which  shall  be  user-definable 
in  the  initial  conditions  for  a  PLBS  scenario  are  the  following: 

Scenario  name/ identifier . 

Mission  description. 

Exercise  type  (platoon  level,  single  tank,  tank  section,  or 
company/team) . 

Names  of  participants,  by  station. 

Friendly  foice  indirect  fire  allocations  and  warning  levels; 
by  munition  type  (high  explosive,  scatterable  mines,  and 
smoke) . 

Terrain  modifiers  (blown  bridges,  closed  roads,  minefields, 
and  barriers)  and  their  locations. 

Target  reference  points  (locations  and  identifiers) . 

Control  measures  (phase  lines,  boundary  lines,  objectives, 
etc.)  and  their  locations. 

Forecasted  routes . 

Simulation  history  recording  (on  or  off)  . 

Simulation  history  recording  interval. 

A  "yes"  or  "no"  for  inclusion  of  each  of  the  following  in  the 
TC ' s  status  window: 

Location  (UTM) . 


Current  fuel  level. 


Current  munition  levels. 

Functionality  (fully,  engagement-only,  movement -only,  or 
dead) . 

Current  terrain  type. 

Pending  alerts/messages. 

For  each  possible  simulaton  entity  (4  TC  controlled  entities, 
10  OPFOR  controlled  entities) : 

Is  or  is  not  in  simulation. 

Type  of  entity. 

Initial  location. 

Initial  orientation. 

Initial  turret  orientation. 

Thermal  imagery  sights  capability. 

For  each  TC  controlled  vehicle: 

Starting  and  warning  fuel  level. 

Starting  and  warning  munitions  levels  (by  weapon  and 
munition  type) . 

Resupply  fuel  amount. 

Resupply  munitions  amount  (by  weapon/ammo  type) . 

To  facilitate  the  defintion  of  scenario  initial  conditions,  a 
user-friendly,  standalone  program  called  initial  £onditions 
Generator  (ICGen)  shall  be  developed.  This  program  shall  have  the 
following  capabilities: 

Create  a  new  set  of  initial  conditions. 

Modifiy  an  existing  set  of  initial  conditions. 

Place  objects  by  positoning  a  cursor  on  a  video  map  image. 

Allow  for  freedom  of  movement  around  the  video  map  terrain. 

User  shall  be  prompted  for  all  information  in  a  menu-driven, 
form-oriented  manner. 

ICGen  shall  be  a  Controller  oriented,  menu-driven,  standalone 
program  which  will  run  either  inside  or  outside  of  the  simulation 
environment.  Using  ICGen,  the  Controller  shall  be  able  to  quickly 
and  easily  create,  modify  or  save  one  or  more  sets  of  initial 


conditions.  ICGen  shall  provide  the  capability  for  its  user  to 
precisely  position  objects  on  video  map  images,  as  well  as 
describe,  in  detail,  the  characteristics  of  all  simulation 
entities,  terrain  modifiers,  control  measures,  forecasted  paths, 
and  target  reference  points. 

The  main  menu  of  ICGen  shall  contain  a  list  of  all  existing 
initial  conditions  files  in  a  specified  library.  The  user  may 
select  one  of  these  files  to  be  used  for  the  default  information, 
or  may  elect  to  create  a  completely  new  file  from  scratch.  Once  a 
file  has  been  specified,  a  submenu  shall  be  displayed  on  the 
monochrome  monitor,  and  a  map  image  along  with  any  default  graphics 
information  shall  be  displayed  on  the  color  monitor.  At  this  point 
the  user  shall  have  the  ability  to  move  around  the  simulation  map 
area  and/or  select  from  the  menu  of  options  displayed  on  the 
monochrome  monitor . 

Using  menu  options  and  form-oriented  data  entry,  on  the 
monochrome  monitor,  the  Controller  will  be  directed  through  the 
creation  of  one  or  more  initial  conditions  database  file(s).  The 
crosshair  cursor  on  the  color  display  will  be  used  to  position  or 
locate  items  in  the  simulation  world.  Using  the  above  techniques, 
the  Controller  shall  have  the  ability  to  create,  add,  delete,  and 
modify  initial  conditions  files  quickly  and  easily. 

Adding  to  a  file.  When  the  ADD  option  is  selected  from  the 
submenu,  the  user  shall  be  presented  with  a  list  of  objects  which 
can  be  added.  After  selecting  the  object  to  be  added,  the 
Controller  is  directed  to  move  the  cursor  crosshair  to  the  desired 
location  (or  mulitple  locations  for  items  such  as  lines  and 
minefields) . 

At  this  point,  if  more  information  is  required  about  the 
object  being  placed,  an  input  form  shall  be  displayed  on  the 
monochrome  monitor.  This  input  form  shall  have  fields  for  each 
piece  of  data  which  describes  the  object .  When  appropriate, 
default  information  shall  be  displayed.  The  Controller  then  moves 
freely  among  the  input  fields  entering  new  data  and/or  altering  the 
default  data  as  desired.  Rigid  error  checking  shall  be  performed 
as  information  is  entered  to  insure  its  validity.  When  an  entry  is 
deemed  invalid,  an  error  message  shall  be  displayed  indicating  why 
it  is  invalid,  along  with  a  description  of  the  valid  range  of  data. 
When  the  form  is  completed  and  accepted,  the  graphics  icon  which 
represents  the  object  being  placed,  shall  appear  on  the  color 
monitor,  overlayed  on  the  map  image.  The  new  entry  shall 
automatically  be  added  to  the  initial  conditions  file.  The  process 
can  be  repeated  for  all  objects  to  be  added  to  an  initial 
conditions  file. 


Deleting  an  entry  in  the  file.  There  shall  be  two  ways  in 
which  an  object  can  be  deleted  when  the  DELETE  menu  option  is 
selected.  Object  deletion  can  be  achieved  by  selecting  from  among 
a  list  of  object  names  or  by  pointing  to  the  icon.  If  the  deletion 


is  to  be  made  by  object  name,  the  user  selects  one  or  more  object 
names  from  a  list  which  is  displayed  on  the  monochrome  monitor. 


If  the  deletion  is  to  be  made  by  object  icon,  the  user  simply 
has  to  position  the  crosshair  over  the  icon(s)  of  the  object  (s),  to 
be  deleted.  When  the  deletion  is  accepted,  by  either  of  the  above 
means,  the  graphic  icon (s)  on  the  color  monitor  are  erased  and  the 
entry (s)  are  deleted  from  the  initial  conditions  file. 

Modifying  an  entry  in  a  file.  When  the  MODIFY  option  is 
selected,  the  object  to  be  modified  is  selected  by  the  same  means 
used  to  delete  an  object;  by  icon  or  by  object  name.  Once  the 
object  to  be  modified  has  been  specified,  the  object  can  be  moved 
and/or  the  information  about  the  object  can  be  changed  on  the  input 
form  displayed  on  the  monochrome  screen.  Once  the  modifications 
have  been  made,  the  graphics  on  the  color  screen  are  redrawn  and 
the  entries  in  the  database  file  are  updated  to  reflect  the 
modifications . 

When  the  Controller  is  satisified  with  the  initial  conditions 
locations  and  descriptions,  the  file  is  saved,  and  the  process  can 
be  repeated  or  the  program  terminated. 

The  ICGen  program  shall  be  invokable  in  two  ways.  First,  by 
the  single  command  "ICGen"  at  the  DOS  prompt  level.  When  the 
program  is  executed  in  this  manner  it  will  be  running  outside  of 
the  PLBS.  This  provides  a  means  to  define  one  or  more  sets  of 
initial  conditions  without  the  entire  simulation  running.  Second, 
ICGen  shall  be  executable  within  a  simulation  run,  by  selecting  a 
menu  option  from  the  Controller's  PLBS  menu.  Invoking  the  ICGen 
program  shall  not  interfere  with  the  operation/execution  of  the 
simulation.  The  Controller  can  either  pause  the  simulation  before 
entering  the  ICGen  program,  or  allow  the  simulation  to  continue 
while  modifying  an  initial  conditions  file.  At  the  point  which  the 
ICGen  menu  option  is  selected,  a  snapshot  of  all  object  locations 
within  the  simulation  shall  be  taken.  This  snapshot  shall  be  saved 
as  a  time-stamped  initial  conditions  file  which  can  then  be  edited 
by  the  Controller  while  the  simulation  continues. 

By  allowing  the  Controller  to  access  the  ICGen  software  from 
within  a  simulation  run,  the  Controller  has  the  ability  to  present 
a  given  situation  in  a  number  of  ways,  easily  and  in  a  timely 
fashion . 

An  additional  requirement  is  that  the  Controller  must  be  able 
to  create  and  place  control  measures  such  as  boundry  lines,  phase 
lines,  and  objectives.  To  facilitate  the  creation  and  placement  of 
control  measures,  ICGen  shall  allow  for  the  addition  and  deletion 
of  the  following  objects: 

Lines . 


Circles . 


Boxes . 


Text . 

Lines  shall  be  defined  by  selecting  two  or  more  points,  a  line 
width  and  a  color.  The  Controller  will  use  the  pointing  device  to 
establish  a  sequence  of  points  that  are  connected  as  they  are 
plotted.  A  graphic  "rubberband”  line  shall  stretch  from  the  last 
point  plotted  to  the  current  crosshair  location  until  the 
Controller  presses  a  button  on  the  pointing  device. 

Circles  shall  be  defined  by  selecting  a  center  point,  a  point 
on  the  perimeter,  a  line  width,  and  a  color. 

Boxes  shall  be  defined  by  selecting  two  points  (opposite 
corners),  a  line  width  and  a  color.  The  Controller  will  again  use 
the  pointing  device  to  select  a  point  which  will  represent  one 
corner  of  the  box.  A  graphic  "rubberband”  box  shall  stretch  from 
the  selected  point  to  the  current  crosshair  location  until  the 
Controller  presses  a  button  on  the  pointing  device. 

Text  shall  be  defined  by  selecting  a  point,  one  of  two  text 
sizes,  a  color,  and  the  text  itself. 


To  provide  maximum  system  flexibility,  the  following 
simulation  data  elements  shall  be  modifiable  through  the  use  of  a 
standard  text  editor: 

Fuel  consumption  rates,  by  entity  type  —  the  rate  each  type 
of  entity  consumes  fuel  —  effective  at  all  times  that  an 
entity's  engine  is  running  (for  TC  controlled  vehicles  only). 

Height  of  smoke  —  effects  line-of-sight  by  adding  to  the 
elevation . 

Height  of  trees  —  effects  line-of-sight  by  adding  to  the 
elevation . 

Height  of  entities  --  effects  line-of-sight  by  adding  to  the 
elevation . 

Five  pre-defined  messages  --  messages  which  may  be  sent  to 
the  Controller  from  the  TC  stations  (80  characters  or  less). 

Entity  viewing  range  —  longest  range  at  which  an  entity  can 
identify  another  entity. 

Weapon  signature  viewing  range  --  longest  range  at  which  an 
entity  can  identify  weapon  signatures. 

Direct  fire  viewing  range  --  longest  range  at  which  an  entity 
can  identify  direct  fire. 
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Indirect  fire  viewing  range  —  longest  range  at  which  an 
entity  can  identify  indirect  fire. 

Scatterable  mines  viewing  range  —  longest  range  at  which  an 
entity  can  identify  scatterable  mines. 

Hand  and  arm  signals  viewing  range  —  longest  range  at  which 
an  entity  can  identify  hand  and  arm  signals. 

Terrain  modifier  viewing  range  --  longest  range  at  which  an 
entity  can  identify  terrain  modifiers  (blown  bridges,  closed 
roads,  exposed  minefields) . 

Smoke  viewing  range  —  longest  range  at  which  an  entity  can 
identify  smoke. 

Maximum  detection  range  —  longest  range  at  which  an  entity 
can  detect  anything. 

Absolute  identification  range  —  longest  range  at  which  an 
entity  can  fully  identify  another  entity. 

Partial  identification  range  —  longest  range  at  which  an 
entity  can  partially  identify  another  entity. 

No  ident if icaton  range  —  longest  range  at  which  an  entity 
can  detect  but  cannot  identify  another  entity. 

Correct  ammo  loaded  delay  factor  —  amount  of  time  it  takes 
the  loader  to  respond  to  a  gunnery  command  if  the  correct 
ammo  is  already  loaded. 

No  ammo  loaded  delay  factor  —  amount  of  time  it  takes  the 
loader  to  respond  to  a  gunnery  command  if  no  ammo  is  loaded. 

Wrong  ammo  loaded  delay  factor  —  amount  of  time  it  takes  the 
loader  to  respond  to  a  gunnery  command  when  the  wrong  ammo  is 
loaded . 

Number  of  salvos  for  friendly  and  enemy  force  indirect  fire. 

Radius  of  effect  for  indirect  fire,  by  munition  type. 

Default  indirect  fire  time  on  target  --  from  time  of  call  by 
the  Controller. 

Time  delay  from  the  time  smoke  is  layed  (by  indirect  fire) 
until  it  has  completely  dissipated. 

Degrees  in  engagement  ID  area  —  degrees  around  the  lay  of  a 
turret  that  the  gunner  can  identify  a  target. 

Degrees  from  turret  lay  for  "closest  target  decision"  (n)  — 
where  "n"  is  used  as  follows:  If  more  than  one  entity  of  the 
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announced  target  type  exists  within  the  "Degrees  in 
engagement  ID  area"  specified  above,  a  determination  must  be 
made  as  to  which  of  the  entities  should  be  engaged.  To  make 
this  decision,  the  following  protocol  must  be  followed: 

Determine  which  entity  is  closest  to  the  lay  of  the 
turret . 


If  the  entity  selected  is  not  within  "n"  number  of  degrees 
of  the  turret  lay,  that  entity  is  selected  for  engagement. 

If  the  entity  selected  xs,  within  "n"  number  of  degrees  of 
the  turret  lay,  are  there  any  other  entities  which  are 
also  within  "n"  number  of  degrees  of  the  turret  lay? 

If  any  other  entities  are  within  "n"  number  of  degrees  of 
the  turret  lay,  the  entity  selected  for  engagement  of 
those  entities  within  "n"  number  of  degrees  of  the  turret 
lay  is  the  entity  which  is  closest  in  range  to  the 
originator  of  the  engagement  (see  section  Engagement  for  a 
more  detailed  explanation  of  this  modifiable  constant) . 

Effective  range  for  machineguns  —  by  type. 

Area  of  coverage  for  Ml  Abrams  tank  coaxial  machinegun  — 
degree  around  the  lay  of  the  turret  for  coaxial  machinegun 
spray . 

The  above  data  elements  shall  be  described  in  detail,  along 
with  all  possible  values  or  ranges,  in  a  standard  modifiable  text 
file. 

Databases 

PLBS  shall  utilize  three  main  databases:  a  conflict  resolution 
database,  a  maximum  speeds  database  and  a  terrain  database.  Each 
will  be  discussed  separately. 

Conflict  Resolution  Database  (CRD) .  The  CRD  contains 
probabilities  of  hit  and  damage  given  a  hit,  for  all  entity 
types,  weapon/munition  types,  and  indirect  fire  munition 
types.  This  database  shall  be  a  text  file  modifiable  by  a 
standard  text  editor. 

Maximum  Speed  Database  (SPEEDS) .  The  SPEEDS  database 
contains  maximum  forward  and  reverse  speeds  for  each  entity 
type,  in  each  terrain  type.  This  database  shall  be  a  text 
file  modifiable  by  a  standard  text  editor. 

Terrain  Database  (AUTODAT) .  The  terrain  database  contains 
feature  and  elevation  data  for  each  30  x  30  meter  subsection 
of  the  PBLS  map  area.  This  database  shall  be  modifiable 
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through  the  use  of  an  off-the-shelf  software  package  called 
AUTODAT .  1 


To  utilize  the  voice  recognition  capability  of  PLBS,  each  TC 
must  train  the  computer  to  recognize  his  voice.  The  process  of 
teaching  the  computer  a  voice  is  called  voice  enrollment  or  voice 
training.  Voice  enrollment  shall  be  accomplished  by  the  use  of 
off-the-shelf  voice  enrollment  software  augmented  by  a 
user-friendly  interface.  This  interface  shall  allow  a  TC  to  enroll 
his  voice  for  all  necessary  words  quickly  and  easily  by  selecting 
from  menus  and  reading  on-screen  directions.  The  voice  enrollment 
process  shall  be  facile  enough  to  allow  one  Controller  to  oversee 
the  simultaneous  enrollment  of  four  TC ' s . 


TERRAIN 

The  functional  requirements  for  terrain  are  to  provide  each 
position  with  knowledge  of  the  terrain  in  which  they  are  operating, 
or  in  the  case  of  the  Controller,  the  terrain  in  which  both  the 
OP FOR  and  friendly  forces  are  operating.  Terrain  functional 
requirements  are  discussed  below  in  terms  of  characteristics, 
elevation,  effects  and  perception. 


Terrain  characteristics  are  the  natural  and/or  man-made 
objects  to  be  found  in  the  tactical  scenarios  inherent  in  PLBS. 

PLBS  shall  provide  for  the  representation  of  two  types  of  terrain 
characteristics;  terrain  features  and  terrain  modifiers. 

Terrain  Features.  The  terrain  features  shall  describe  the 
actual  terrain  itself,  before  any  modifications  to  the  terrain  have 
been  made.  The  terrain  features  which  shall  be  represented  are  as 
follows : 


Primary  road. 


Shallow  water 


Secondary  road. 


Deep  water . 


Trail 


Clear  . 


Bridge . 

Light  woods. 
Heavy  woods . 


Rough . 
Cliff  . 


Barrier 


1  A  description  of  AUTODAT  can  be  found  in  Perceptronics,  Inc.  AUTODAT 
promotional  literature. 


Terrain  features  shall  be  described  at  a  30  meter  resolution 
and  contained  in  a  database  describing  the  video  disc  used  for 
PLBS .  This  database  shall  be  created/modified  through  the  use  of  a 
user-friendly,  standalone  (outside  of  the  simulation)  program, 
called  AUTODAT,  designed  specifically  to  digitize  the  terrain  and 
elevation  of  video  disc  maps. 

The  representation  of  terrain  shall  be  achieved  by  the  display 
of  fixed,  non-modif iable,  video  disc  map  imagery  on  a  color 
monitor . 

Terrain  Modifiers.  Terrain  modifiers  shall  describe  changes 
to  the  terrain  features.  The  terrain  modifiers  which  shall  be 
represented  are  as  follows: 

Blown  bridge. 

Closed  Road. 

Minefield  (hidden  and  exposed) . 

Barrier . 

The  placement  of  terrain  modifiers,  at  a  30  meter  resolution, 
shall  be  achieved,  at  simulation  initialization,  through  the  use  of 
a  user-friendly,  standalone  program,  called  ICGen  (see  section 
Initialization  for  a  description  of  the  functional  requirements  for 
ICGen)  . 

Terrain  modifiers  (except  for  hidden  minefields)  shall  be 
represented  by  graphic  icons  overlayed  on  the  video  disc  map 
imagery.  An  icon,  representing  the  terrain  modifier,  shall  be 
displayed  in  each  30  x  30  meter  terrain  feature  grid  which  is 
changed  by  a  terrain  modifier.  Detection  and  identification 
factors  shall  be  considered  in  determining  whether  or  not  to 
display  terrain  modifiers  (see  section  Detection/Identification) . 

Elevation 

Elevation  is  the  height  above  the  level  of  the  sea.  Elevation 
shall  be  described,  in  increments  of  10  meters,  at  a  30  meter 
resolution  and  contained  in  a  database  describing  the  video  disc 
used  for  PLBS.  This  database  shall  be  created/modified  through  the 
use  of  a  user-friendly,  standalone  (outside  of  the  simulation) 
program,  called  AUTODAT,  designed  specifically  to  digitize  the 
terrain  and  elevation  of  video  disc  maps.  The  representation  of 
elevation  shall  be  achieved  by  the  display  of  fixed, 
non-modif iable,  video  disc  map  imagery  on  a  color  monitor. 
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Terrain  characteristics  and  elevation  have  an  effect  on  both 
traf f icability  and  Detection/Identification. 


Traf f icability  is  the  effect  of  terrain  on  movement  rates  and 
traversability  (e.g.,  tanks  can  traverse  open,  relatively  flat 
grasslands,  but  cannot  traverse  rivers) .  Traf f icability  functional 
requirements  do  not  dictate  any  representation  requirements,  but 
dictate  several  modeling  requirements  (i.e.,  friendly  tanks  should 
not  be  permitted  to  move  at  70KPH  in  wooded  terrain) .  These 
modeling  requirements  are  specified  later  in  section  Movement. 

Detection/Identification  concerns  the  effect  of  terrain 
characteristics  and  elevation  on  the  detection  and  subsequent 
identification  of  objects,  events,  and  conditions  of  the  simulation 
environment.  Detection/Ident if ication  requirements  are  specified 
later  in  section  Detection/Identification. 


Each  PLBS  position  requires  a  somewhat  different  perception  of 
terrain.  This  difference  in  perception  only  relates  to  the  area  or 
size  of  the  piece  (and,  consequently  the  scale)  of  the  terrain 
which  is  represented  to  each  position.  Perception  requirements  for 
each  PLBS  positon  are  described  separately. 

TC ' s  —  Each  TC  shall  have  the  ability  to  select  from  3 
different  views  of  the  terrain  in  which  he  is  operating. 

Each  view,  close,  middle  and  long  range,  shall  be  a  different 
size,  but  all  shall  provide  a  360°  "birds-eye"  view  of  the 
terrain.  Each  view  will  be  of  a  United  States  Geological 
Survey  filmed  map.  The  size  of  frames  (what  can  be  displayed 
on  a  screen  at  any  given  time)  at  each  view  shall  be  as 
follows : 

Close  Range  —  600  meters  X  450  meters 

Middle  Range  --  3000  meters  X  2250  meters 

Long  Range  —  6600  meters  X  4950  meters 

OP FOR  —  The  OPFOR  station  has  the  responsibility  of 
controlling  a  number  of  entities.  For  each  entity  the  OPFOR 
station  is  controlling,  the  OPFOR  shall  be  able  to  view  the 
terrain  in  exactly  the  same  manner  as  the  TC '  s .  This  means 
that  for  any  entity  controlled  at  the  OPFOR  station,  the 
OPFOR  shall  be  allowed  to  select  from  the  3  different  views 
of  the  terrain  in  which  the  entity  being  controlled  is 
operating . 

Controller  --  The  Controller  shall  be  allowed  to  select  from 
one  of  15  different  views  of  the  simulation  terrain.  These 
views  are  as  follows: 

Platoon  Leader 


Platoon  Sergeant 


Wingman  1  and  2 

OPFOR  Controlled  Entity  1  through  10 
Controller's  World  View 


When  any  of  the  four  TC  views  are  selected,  the  terrain 
displayed  shall  be  the  terrain  view  which  is  currently  being 
viewed  by  the  station  which  is  controlling  the  entity 
selected.  This  view  shall  be  centered  around  the  selected 
entity . 

Example:  The  Platoon  Leader's  station  is  displaying 

the  Close  Range  view.  The  Controller  selects  to  view  the 
Platoon  Leader's  display.  The  Controller's  display  is  then 
changed  to  the  Close  Range  view  centered  around  the  Platoon 
Leader's  vehicle. 

When  any  of  the  OPFOR  views  are  selected,  the  terrain 
displayed  shall  be  the  terrain  view  which  is,  or  would  be 
viewed  by  the  station  which  is  controlling  the  entity 
selected.  This  view  shall  be  centered  around  the  selected 
entity . 

Example:  The  OPFOR  station  is  displaying  the  Close 

Range  view  for  Entity  #2.  The  Controller  selects  to  view 
OPFOR  controlled  Entity  #2's  display.  The  Controller's 
display  is  then  changed  to  the  Close  Range  view  centered 
around  the  OPFOR' s  Entity  #2. 

Example:  The  OPFOR  station  is  displaying  the  Close 

Range  view  for  Entity  #2.  The  OPFOR  changes  to  viewing  his 
Entity  #1  at  the  Long  Range  view.  The  Controller  selects  to 
view  OPFOR  controlled  Entity  #2's  display.  The  Controller's 
display  is  then  changed  to  the  Close  Range  view  centered 
around  the  OPFOR' s  Entity  #2. 

The  Controller's  World  view  is  a  topographical  map  with 
a  frame  size  of  6000  meters  x  4500  meters.  When  the 
Controller's  World  view  is  selected  for  the  first  time, 
during  a  simulation  run,  the  World  view  is  displayed  centered 
around  the  Platoon  Leader's  vehicle.  The  Controller  then  has 
the  ability  to  move  freely  around  the  World  view  by  panning 
right,  left,  up  or  down.  After  exiting  and  reentering  this 
mode,  the  World  view  is  displayed  at  the  same  place  it  was 
previously  exited  from. 

At  all  stations,  after  selecting  one  of  the  terrain  views 
other  than  the  Controller's  World  view,  the  frame  displayed  shall 
be  a  snap-shot  of  the  terrain,  at  the  selected  view,  centered 
around  the  vehicle  being  controlled.  As  the  controlled 
vehicle  approaches  a  boundry  of  the  current  frame,  the  display 


shall  be  updated  with  a  different  frame  to  reflect  the  new 
surrounding  terrain. 

At  any  given  time,  an  entire  segment  of  terrain  is  visable  to 
the  TC ' s  and  the  OPFOR  without  consideration  of  line-of-sight . 
Because  the  viewer  can  see  more  of  the  terrain  features  than  would 
be  viewable  in  the  field,  yet  will  only  be  allowed  to  see  the 
terrain  modifiers,  entities,  events  and  conditions  which  are  within 
line-of-sight  of  the  vehicle  being  controlled  (see  Section 
Detection/Identification),  it  is  necessary  to  provide  the  viewer 
with  some  indication  of  what  terrain  is  actually  within 
line-of-sight.  For  this  reason,  while  viewing  any  one  of  the 
terrain  perspectives,  the  TC 1 s  and  the  OPFOR  shall  be  provided  with 
an  option  to  call  up  a  graphic  display  of  line-of-sight.  This 
display  shall  appear  as  an  overlay  on  the  video  disc  map  image 
until  an  option  to  clear  it  is  selected.  This  display  shall  be  a 
45  degree  line-of-sight  fan  centered  around  the  turret  and 
extending  from  the  controlled  vehicle  to  the  edge  of  the  display. 
The  fan  shall  consist  of  solid  lines  through  those  30  x  30  meter 
terrain  areas  for  which  the  viewer  does  not  have  line-of-sight,  and 
no  lines  through  those  30  x  30  meter  terrain  areas  for  which  the 
viewer  does  have  line-of-sight.  To  invoke  this  function  the  entity 
being  controlled  must  be  stationary. 


MOVEMENT 

Determining  what  moves,  the  rate  at  which  something  moves,  the 
control  of  movement,  and  the  perception  of  movement  are  all 
critical  to  PLBS  achieving  its  objectives.  The  movement  functional 
requirements  vary,  depending  on  the  PLBS  position  being  addressed, 
and  will  be  discussed  in  the  following  subsections: 

TC  Vehicle  Movement. 

OPFOR  Controlled  Entity  Movement. 

Controller  Movement  Monitoring. 

Each  of  these  subsections  will  be  discussed  individually  in 
terms  of  direction,  rate,  control,  and  perception.  For  purposes  of 
this  discussion,  these  terms  are  defined  as  follows: 

Direction  --  The  line  or  course  (expressed  in  terms  of 

degrees)  on  which  a  vehicle  moves. 

Rate  --  The  speed  at  which  a  vehicle  moves. 

Control  —  The  manner  in  which  bot-.  the  direction  and  rate  of 

movement  for  a  vehicle  are  controlled. 


Perception  —  The  visual  image  of  vehicle  movement. 


The  platoon  leader,  platoon  sergeant,  and  two  wingman 
commanders  will  each  control  the  movement  of  his  own  vehicle  (tank 
or  PC) .  In  this  context,  movement  includes  both  the  direction  in 
which  a  vehicle  moves  and  its  rate  of  speed.  Specifically,  this 
requires  PLBS  to  satisfy  the  following  functional  requirements: 

Direction  —  Each  TC  shall  be  capable  of  moving  his  vechicle 
in  any  direction  at  any  time  during  the  simulation. 

Rate  --  PLBS  shall  limit  the  rate  at  which  TC  vehicles  can 
move.  The  maximum  forward  and  reverse  rates  of  speed  differ 
depending  upon  the  type  of  vehicle  being  controlled  (tank  or 
PC)  and  the  type  of  terrain  (heavy  woods,  primary  road,  etc.) 
over  which  movement  is  taking  place.  The  maximum  speeds  for 
each  type  of  vehicle,  in  each  type  of  terrain,  for  both 
forward  and  reverse  movement,  shall  be  specified  in  a 
modifable  database  called  SPEEDS.  This  database  shall  be 
easily  modifiable  at  the  initialization  stage  of  a  simulation 
run  (see  section  Initialization) . 

Control  —  Control  of  TC  vehicles  dictate  the  following 
movement  control  functional  requirements: 

Engine  Status  —  Since  vehicles  consume  fuel,  vehicle 
commander's  may  choose  to  turn  their  engines  off  while 
stationary.  For  this  reason,  PLBS  shall  provide  a  means  by 
which  the  TC's  can  control  the  running  of  their  vehicle's 
engine.  Each  TC  position  shall  be  provided  the  ability  to 
turn  the  vehicle  engine  to  "off"  and  "on".  In  the  two  person 
mode,  the  vehicle  commander  will  issue  a  voice  command  to  the 
human  dr iver/gunner  to  turn  the  engine  "on"  or  "off".  The 
human  driver/gunner  will  then  select  the  appropriate  engine 
control  in  response.  In  the  one  person  mode,  the  vehicle 
commander  himself  must  select  the  appropriate  engine  control 
to  turn  the  engine  either  "on"  or  "off". 

Movement  Ability  —  When  a  vehicle's  engine  is  not  running, 
the  vehicle  is  out  of  fuel,  the  vehicle  is  engagement-only 
functional  (tracks  have  been  blown  off) ,  or  the  vehicle  is 
dead,  all  movement  capability  is  disabled. 

Controlling  Direction  and  Rate  --  Each  TC  shall  have  control 
of  both  the  direction  and  rate  at  which  his  vehicle  is 
moving.  To  achieve  this,  PLBS  shall  provide  each  TC  station 
with  the  capability  of  direct  vehicle  movement  control. 

In  the  two  person  mode,  the  vehicle  commander  will 
present  verbal  directives  to  the  human  driver/gunner.  The 
human  driver/gunner  will  then  take  the  necessary  action  to 
control  the  movement  of  the  vehicle.  In  the  one  person  mode, 
the  vehicle  commander  himself  must  take  the  necessary  action 
to  control  the  movement  of  his  vehicle. 
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To  facilitate  direct  movement  control,  a  joystick  type 
device  shall  be  utilized  which  will  facilitate  both  direction 
and  speed  control.  This  input  device  shall  be  the  same  for 
both  modes  of  operation  (single  and  two  person) . 

Directional  control  shall  facilitate  directional  changes 
as  small  as  15  degrees  as  well  as  forward  and  reverse 
movement . 

Rate  control  shall  facilitate  speed  adjustments  as  small 
as  5  KPH  up  to  the  previously  specified  maximum  rate  of  speed 
for  the  vehicle  type  in  the  terrain  being  traversed. 

Perception  --  Each  TC  must  always  be  aware  of  the  following 
regarding  his  tank: 

Tank  Orientation  —  Because  the  TC  must  be  aware  of  the 
orientation  of  his  vehicle  before  he  can  determine  the 
appropriate  directional  changes  to  be  made,  the  front  of  a 
TC ' s  vehicle  must  always  be  indicated.  To  achieve  this,  PLBS 
shall  represent  the  vehicle,  on  the  TC ' s  display,  in  a  manner 
which  clearly  identifies  the  front  of  the  vehicle  (e.g.  for  a 
tank  this  shall  be  a  rectangle  with  a  notch  cut  out  at  the 
f ront )  . 

Direction  of  Movement  --  TC ' s  must  be  made  aware  of  the 
direction  of  that  movement.  This  shall  be  achieved  by  the 
repositioning  (updating)  of  the  vehicle  icon  on  the  TC ' s 
display  as  it  moves  across  the  terrain. 

Rate  of  Movement  —  Each  TC  must  be  capable  of  discerning  the 
movement  rate  of  his  vehicle.  To  accomplish  this,  a  speed 
indicator  shall  be  present  on  the  TC ' s  display.  The  speed 
indicator  shall  be  a  graphic  representation  of  speed 
overlayed  on  the  color  monitor.  When  the  vehicle  is  not 
moving  the  speed  indicator  shall  read  "0".  When  the  vehicle 
is  moving,  the  speed  indicator  shall  be  a  number  which 
represents  the  number  of  kilometers  per  hour  (KPH)  at  which 
the  vehicle  is  travelling  (e.g.  "25"). 

Engine  Status  —  PLBS  shall  provide  a  constant  cue  to  each  TC 
signifying  whether  or  not  the  engine  on  his  vehicle  is 
running.  This  shall  be  accomplished  by  the  absence  or 
presence  of  the  speed  indicator.  The  speed  indicator  shall 
be  present  if  the  engine  of  the  vehicle  is  turned  on  and 
shall  not  be  present  if  the  engine  is  off. 

CP FOR  Vehicle  Movement 

One  person  will  control  the  movement  of  all  OPFOR  controlled 
entities  (i.e.,  friendly  and  enemy  tanks,  friendly  and  enemy  PC's, 
friendly  and  enemy  trucks,  friendly  and  enemy  helicopters,  and 
enemy  man-packed  saggers) .  PLBS,  therefore,  must  provide  the  OPFOR 
the  capability  to  move  his  vehicles  both  individually  and  together 
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as  a  group.  This  dictates  the  following  OPFOR  vehicle  movement 
functional  requirements: 

Direction  —  At  any  point  on  a  terrain  representation,  and  at 
any  time  during  the  simulation,  the  OPFOR  must  be  capable  of 
moving  any  of  the  entities  he  controls  in  any  direction.  He 
must  be  permitted  to  move  each  of  his  entities  individually  as 
well  as  in  unison. 

Rate  --  Rates  of  movement  shall  be  limitied  for  OPFOR 
controlled  entities  in  the  same  manner  as  for  TC  vehicles  (see 
TC  Vehicle  Movement:  Rate) . 

Control  —  Control  of  OPFOR  controlled  entities  dictate  the 
following  movement  control  requirements: 

Engine  Status  --  If  present,  OPFOR  controlled  entity  engines 
shall  always  be  assumed  to  be  running.  Therefore,  the  OPFOR 
need  not  be  provided  with  engine  control  capability. 

Movement  Ability  —  Engines  of  the  OPFOR  controlled  entities 
shall  always  be  running,  and  fuel  shall  not  be  monitored. 

When  an  OPFOR  controlled  entity  is  engagement-only  functional 
(tracks  have  been  blown  off)  or  the  enitity  is  dead,  all 
movement  capability  is  disabled. 

Controlling  Direction  and  Rate  —  OPFOR  entity  movement 
control  shall  allow  for  individual  entity  and  group  control. 
This  requires  that  the  PLBS  allow  the  OPFOR  to  group  (and 
disband)  two  or  more  entities.  PLBS  shall  allow  the  OPFOR  to 
select  the  grouping  option,  and  subsequently  denote  which 
entities  shall  be  included  in  the  group.  Up  to  5  groups 
shall  be  allowed.  When  entities  are  grouped,  a  directional 
command  given  to  any  member  of  the  group  shall  effect  the 
entire  group. 

The  OPFOR  must  have  the  flexiblity  of  either  directly 
controlling  the  movement  of  an  entity  or  a  group  of  entities, 
or  forcasting  a  route  for  an  entity  or  group  of  entities  to 
follow . 

To  facilitate  forecasted  path  movement  control,  a 
combination  of  input  devices  shall  be  utilized:  a  joystick 
type  device  and  a  function  keypad. 

When  the  forecast  route  option  is  selected,  the  joystick 
device  changes  mode  from  direct  movement  control  and  is  then 
used  to  select  up  to  25  discrete  points.  As  the  points  are 
selected,  they  are  connected  to  designate  the  route  to 
follow.  Once  the  forecasted  route  has  been  designated,  the 
joystick  device  then  reverts  back  to  direct  movement  control 
mode  and  an  indicator  showing  which  entities  are  in 
forecasted  mode  is  displayed  on  the  OPFOR  status  display. 
Only  speed  control  via  the  joystick  device  shall  be  allowed 
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while  a  vehicle  is  following  a  forecasted  path.  If  a 
directional  change  is  made  via  the  joystick  device,  the 
forecasted  path  shall  be  aborted.  Upon  reaching  the  end  of  a 
forecasted  route  the  entity  shall  cease  to  move.  Unless 
direct  speed  control  is  initiated,  the  entity  will  attempt  to 
always  travel  at  the  maximum  speed  for  the  terrain  type  being 
traversed . 

Direct  movement  control  shall  be  the  same  for  the  OPFOR 
as  it  is  for  the  TC ' s  (see  section  TC  Vehicle  Movement: 
Control)  with  the  following  exceptions: 

When  the  OPFOR  issues  a  movement  command  (either 
direct  or  forecasted) ,  these  commands  shall  effect 
either  a  single  entity,  or,  in  the  case  where  the 
entity  being  commanded  is  a  member  of  a  group,  shall 
effect  all  group  members. 

For  group  movement,  the  speed  of  all  entities  of  a 
group  is  assumed  to  be  the  speed  at  which  the  slowest 
entity  is  moving  (based  upon  both  vehicle  type  and 
terrain  type) . 

Perception  --  The  OPFOR  must  be  aware  of  the  location  and 
movement  of  each  of  the  vehicles  under  his  control  at  all 
times.  Line  of  sight  or  intervisibility  among  OPFOR  vehicles 
is  not  of  concern.  Therefore,  all  OPFOR  controlled  entities 
shall  be  displayed,  if  possible,  on  the  OPFOR  display  without 
regard  to  detection  and  identification  considerations  (see 
section  Detection/Identification) .  Entity  orientation, 
direction  of  movement,  and  rate  of  movement  shall  be 
represented  in  the  same  fashion  as  for  the  TC's. 

Controller  Movement  Monitoring 

A  single  individual  will  be  responsible  for  controlling  the 
entire  simulation.  With  respect  to  movement  functional 
requirements  for  PLBS,  it  is  the  monitoring  responsibilities  of  the 
Controller  that  are  of  most  concern.  To  assess  tactical  situations 
and  provide  proper  feedback  to  TC’s,  the  Controller  must  always  be 
aware  of  what  is  moving,  in  what  direction  and  at  what  speed.  This 
necessitates  that  PLBS  satisfy  the  following  functional 
requirements : 

Direction  —  The  Controller  must  be  aware  at  all  times  of  the 
direction  of  movement  of  all  entities  (friendly  and  OPFOR)  in 
the  simulation . 

Rate  —  The  Controller  must  be  aware  of  the  movement  rate  of 
each  entity  in  the  simulation. 

Control  —  The  Controller  shall  not  have  any  control  over  the 
direction  of  movement  or  movement  rate  of  either  OPFOR  or 
friendly  forces. 
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Perception  —  The  Controller  must  always  be  aware  of  the 
following : 

Vehicle  Orientation  —  The  front  of  any  friendly  and  OPFOR 
entities  must  be  obvious  to  the  Controller. 

Movement  —  The  direction  in  which  any  simulation  entity  is 
moving  must  be  portrayed  to  the  Controller. 

Movement  Rate  —  The  movement  rate  of  any  simulation  entity 
must  be  discernable  to  the  Controller.  This  does  not 
necessarily  dictate  that  all  movement  must  be  depicted  to 
scale  nor  depicted  in  continuous  motion.  For  example,  a 
symbol  could  move  in  1/4  inch  increments  as  opposed  to  moving 
continuously  at  an  extremely  slow,  possibly  nondetectable, 
rate.  However,  the  Controller  shall  be  able  to  distinguish 
rapid  from  slow  movement  rates. 


DETECTION/ IDENTIFICATION 

These  functional  requirements  concern  the  relevant  objects, 
events,  and  conditions  of  the  simulation  environment  which  may  be 
detected  and  subsequently  identified  by  each  participant  in  PLBS . 
These  functional  requirements  not  only  concern  what  can  be  seen  and 
heard,  but  also  address  the  manner  in  which  the  stimuli  are  to  be 
represented  to  the  PLBS  positions.  In  general,  these  functional 
requirements  consider  the  detection  of  the  following: 

Entities  —  Tanks,  personnel  carriers,  trucks,  helicopters, 
and  man-packed  saggers. 

Instantaneous  Events  — -  Weapons  signatures,  explosions,  and 
other  noises  and  flashes . 

Transient  Conditions  —  Smoke. 

These  functional  requirements  also  address  how  to  determine 
when  detection  has  been  lost  by  each  PLBS  position. 

It  should  be  noted  that  detection,  in  this  context,  is  not 
restricted  to  detecting  or  not  detecting  only  opponent  forces 
(i.e.,  OPFOR  detecting  friendly  forces  and  friendly  forces 
detecting  OPFOR  forces) .  In  this  case,  detection  also  means  that 
TC  controlled  friendly  forces  shall  have  the  ability  to  detect 
other  vehicles  in  their  platoon  that  are  within  their  field  of 
vision;  and  in  the  case  of  the  OPFOR  stat  ion,  that  all  OPFOR 
controlled  entities  shall  be  represented  to  the  OPFOR  at  all  times 
regardless  of  line-of-sight  restrictions.  However,  the  OPFOR 
ability  to  detect  TC  friendly  forces  shall  be  restricted  by 
line-of-sight  and  other  considerations. 
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The  Detection/ Ident if ication  functional  requirements  for  PLBS 
are  best  defined  in  terms  of  visual  detection/identification, 
auditory  detection,  and  representation  requirements. 

Visual  Detection/Identif ication 

To  determine  whether  an  OPFOR  or  friendly  force  entity  detects 
something  visually,  and  if  it  is  detected  how  well  it  is 
identified,  several  factors  must  be  taken  into  consideration.  To 
determine  detection,  two  questions  must  be  answered:  "Can  it  be 
detected?"  and  "Do  they  see  it?"  The  first  question  is  answered  by 
determining  whether  or  not  line-of-sight  exists  between  the  objects 
in  question.  Terrain  characteristics,  elevation,  vehicle  height, 
and  existance/height  of  obscurants  (smoke)  located  between  the 
potential  viewer  and  the  potentially  detectable  object  shall  be 
considered  in  determining  line-of-sight.  The  height  of  vehicles 
and  smoke  shall  be  constants,  modifiable  at  initialization  (see 
section  Initialization) .  If  line-of-sight  does  exist,  the  second 
question,  "Do  they  see  it?",  shall  then  be  answered.  The 
simulation  shall  answer  the  second  question,  "Do  they  see  it?",  by 
considering  range.  The  "Do  they  see  it?"  element  of  detection 
shall  be  answered  "yes"  if  the  range  between  the  viewer  and  object 
is  less  than  the  maximum  detection  range.  This  range  shall  be 
modifiable  at  system  initialization  (see  section  Init ializaton) . 

If  something  is  detected,  the  degree  of  identification  shall 
then  be  determined.  PLBS  shall  provide  three  degrees  of 
identification:  absolute  identification,  partial  identification, 
and  no  identification.  Each  of  these  degrees  shall  be  based  upon 
range.  Each  of  these  three  maximum  ranges  shall  be  modifiable  at 
system  initialization  (see  section  Initialization). 

In  determining  detection  and  identification,  PLBS  shall 
utilize  the  following  set  of  rules  for  each  type  of  potentially 
detectable  and  identifiable  objects: 

Entities  —  At  the  TC  stations,  entities  shall  be  detected 
only  if  they  are  within  the  line-of-sight  and  entity  viewing 
range  of  the  TC ' s  vehicle.  The  degree  of  identification 
shall  be  based  upon  the  distance  between  the  TC ' s  vehicle  and 
the  entity  detected.  At  the  OPFOR  station,  TC  vehicles  shall 
be  detected  only  if  they  are  within  the  line-of-sight  and 
entity  viewing  range  of  the  selected  OPFOR  controlled  entity. 
The  degree  of  identification  shall  be  based  upon  the  distance 
between  the  selected  OPFOR  controlled  entity  and  the  TC 
vehicle  detected.  All  OPFOR  controlled  entities  shall  always 
be  detected  and  fully  identified  by  the  selected  OPFOR 
controlled  entity  at  the  OPFOR  station. 

Weapon  Signatures  —  At  the  TC  stations,  weapon  signatures 
from  all  entities  (friendly  and  enemy)  shall  be  detected:  1) 
if  the  entity  firing  the  weapon  is  within  the  line-of-sight 
and  weapon  signature  viewing  range  of  the  TC ' s  vehicle,  or  2) 
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if  the  entity  firing  the  weapon  is  not  within  1 ine-of-sight , 
but  is  firing  at  the  TC ’ s  vehicle.  The  degree  of 
identification,  given  detection,  shall  always  be  full 
identification.  At  the  OPFOR  station,  weapon  signatures  from 
TC  weapon  systems  shall  be  detected:  1)  if  the  TC  vehicle, 
firing  the  weapon  is  within  the  line-of-sight  and  weapon 
signature  viewing  range  of  the  selected  OPFOR  controlled 
entity,  or  2)  if  the  TC  vehicle  firing  the  weapon  is  not 
within  line-of-sight,  but  is  firing  at  the  selected  OPFOR 
controlled  entity.  The  degree  of  identification,  given 
detection,  shall  always  be  full  identification.  Weapon 
signatures  from  OPFOR  controlled  weapon  systems  shall  always 
be  detected  by  the  selected  OPFOR  controlled  entity.  The 
degree  of  identification,  given  detection,  shall  always  be 
full  identification. 
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Direct  Fire  Hits  --  At  the  TC  stations,  explosions  from 
direct  fire  hits  shall  only  be  detected  if  the  entity  being 
fired  upon  is  within  the  line-of-sight  and  direct  fire 
viewing  range  of  the  TC ' s  vehicle.  The  degree  of 
identification,  given  detection,  shall  always  be  full 
identification.  At  the  OPFOR  station,  explosions  from  direct 
fire  hits  on  TC  vehicles  shall  only  be  detected  if  the  entity 
being  fired  upon  is  within  the  line-of-sight  and  direct  fire 
viewing  range  of  the  selected  OPFOR  controlled  entity.  The 
degree  of  identification,  given  detection,  shall  always  be 
full  identification.  Exposions  from  direct  fire  hits  on 
OPFOR  controlled  entities  shall  always  be  detected  by  the 
selected  OPFOR  controlled  entity.  The  degree  of 
identification,  given  detection,  shall  always  be  full 
identification . 
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Indirect  Fire  —  At  the  TC  stations,  explosions  from  indirect 
fire  shall  only  be  detected  if  the  30  x  30  meter  terrain  area 
being  fired  upon  is  within  the  indirect  fire  viewing  range  of 
the  TC ' s  vehicle.  The  degree  of  identification,  given 
detection,  shall  always  be  full  identification.  At  the  OPFOR 
station,  explosions  from  indirect  fire  shall  always  be 
detected  by  the  selected  OPFOR  controlled  entity.  The  degree 
of  identification,  given  detection,  shall  always  be  full 
identification.  Once  scatterable  mines  have  been  layed  (by 
indirect  fire)  detection  shall  occur  only  if  the  30  x  30 
meter  terrain  area  covered  is  within  the  scatterable  mines 
viewing  range  of  the  entity  being  controlled.  The  degree  of 
identification,  given  detection,  shall  always  be  full 
identification . 

Hand  and  Arm  Signals  —  At  the  TC  and  OPFOR  stations,  hand 
and  arm  signals  (from  TC  vehicles  only)  shall  only  be 
detected  if  the  vehicle  giving  the  signal  is  within  the 
line-of-sight  and  hand  and  arm  signal  viewing  range  of  the 
entity  being  controlled.  The  degree  of  identification,  given 
detection,  shall  always  be  full  identification. 
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Terrain  Modifiers  —  At  the  TC  and  OPFOR  stations,  terrain 
modifiers  shall  only  be  detected  if  the  30  x  30  meter  terrain 
area  which  is  modified  is  within  the  terrain  modifier  viewing 
range  of  the  entity  being  controlled.  The  degree  of 
identif icaton,  given  detection,  shall  always  be  full 
identification . 


Smoke  --  At  the  TC  stations,  smoke  shall  only  be  detected  if 
the  30  x  30  meter  terrain  area  filled  is  within  the  smoke 
viewing  range  of  the  TC ' s  vehicle.  The  degree  of 
identification,  given  detection,  shall  always  be  full 
identification.  At  the  OPFOR  station,  smoke  shall  always  be 
detected  by  the  selected  OPFOR  controlled  entity.  The  degree 
of  identification,  given  detection,  shall  always  be  full 
identification.  Beyond  the  detection  of  smoke  itself,  is  the 
effect  of  smoke  on  the  detection  and  identification  of  other 
objects.  If  a  entity  has  thermal  imagery  sights  (TIS) ,  smoke 
shall  not  affect  that  vehicles  detection  and  identification 
capability  since  TIS  enables  sight  through  smoke.  If  an 
entity  does  not  have  TIS,  line-of-sight  will  be  affected  by 
the  area  and  height  of  the  smoke . 

The  entity  viewing  range,  weapon  signature  viewing  range, 
direct  fire  viewing  range,  indirect  fire  viewing  range,  scatterable 
mines  viewing  range,  hand  and  arm  signal  viewing  range,  terrain 
modifier  viewing  range,  smoke  viewing  range,  full  identification 
range,  partial  identification  range,  no  identification  range,  and 
TIS  capability  shall  be  specified  for  each  PLBS  entity  type.  These 
data  elements  shall  be  modifiable  constants  which  are  accessable  at 
initialization  through  the  use  of  the  ICGen  program  (see  section 
Initialization).  By  modifying  the  above  values  the  effects  of 
vehicle  sighting  devices  (binoculars,  TIS)  can  be  simulated. 


An  auditory  cue  shall  be  sounded  when  an  entity  receives  a 
direct  hit  either  from  direct  or  indirect  fire.  The  receiving  fire 
cue  shall  only  be  sounded  at  the  station  controlling  the  fired  upon 
and  hit  entity. 


Given  that  PLBS  has  determined  that  the  occupants  of  a  PLBS 
entity  (OPFOR  and/or  friendly)  have  visually  detected  something 
(e.g.,  vehicle  or  weapon  signature)  or  are  to  be  provided  with  an 
auditory  cue,  PLBS  shall  represent  this  cue  in  some  way  to  the 
appropriate  vehicle(s).  Specifically,  these  cue  representation 
requirements  are  as  follows: 

Auditory  --  The  auditory  cue  sounded  shall  be  able  to  be 
heard  while  the  TC  or  OPFOR  player  is  wearing  a  CVC  helmet  or 
headset . 
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Location  of  Detected  Object,  Event,  or  Condition  —  This 
representation  requirement  is  twofold.  First,  PLBS  shall 
designate  to  the  detector  the  location  of  the  object,  event, 
or  condition.  Second,  the  system  shall  represent  the  object, 
event,  or  condition  itself  in  a  manner  which  permits  the 
detector  to  distinguish  it  to  some  degree. 

Identification  of  Object,  Event,  or  Condition  —  Because 
events  and  conditions  are  either  detected  and  fully 
identified,  or  not  detected  at  all,  they  shall  be  represented 
by  PLBS  in  only  one  manner.  Each  event  and  condition  shall 
be  represented  graphically  by  a  uniquely  identifiable  icon. 
Entities,  however,  have  three  (3)  different  levels  of 
identification,  given  detection.  For  each  type  of  entity, 
PLBS  shall  present  three  (3)  different  graphic 
representations;  one  for  each  identification  level.  The 
following  table  contains  a  description  of  the  different 
degrees  of  identification  and  the  resulting  graphic 
representation : 


Unidentified 


Partially  Identified 


Fully  Identified 


Unrecognizible  Entity 
(black  square) 

Tank,  PC,  troops,  truck 
or  helicopter  (green 
icons) 

Tank,  PC,  troops,  truck, 
or  helicopter  (red  or 
blue  icons) 


At  the  fully  identified  level,  TC  vehicles  shall  be 
distinguished  not  only  by  the  type  of  vehicle  they  are,  but 
also  by  which  member  they  are  of  the  platoon.  This  shall  be 
accomplished  by  displaying  the  turret  of  each  TC  vehicle  in  a 
different  color. 

Loss  of  Detection/Identification  —  PLBS  shall  provide  some 
form  of  notification  that  detection  of  an  object  has  been 
lost  or  identification  has  been  degraded.  This  shall  be 
achieved  by  eliminating  or  changing  the  graphic  portrayal  of 
the  object  for  which  detection  has  been  lost  or 
identification  has  been  degraded. 

Detection  and  identification  shall  not  limit  what  can  be 
viewed  at  the  World  View  for  the  Controller  station.  At  any  time 
during  a  simulation  run,  the  Controller  shall  be  allowed  to  select, 
or  turn  on  and  off,  the  display  of  each  category  of  entities, 
events  and  conditions  on  this  display.  This  will  allow  the 
Conroller  to  declutter  his  special  view  so  that  it  contains  only 


the  display  of  information  which  he  is  interested  in  at  any  given 
t  ime  . 


The  OPFOR  needs  to  be  alerted  when  any  of  the  entities  he  is 
controlling  detects  a  TC  vehicle.  For  this  reason,  at  the  OPFOR 
station,  when  an  OPFOR  controlled  entity  detects  a  TC  vehicle,  the 
status  line  for  the  detecting  entity,  on  the  OPFOR  status  screen, 
shall  be  highlighted  with  an  asterick. 


ENGAGEMENT 


The  purpose  of  the  engagement  functional  requirements  for  PLBS 
is  to  resolve  all  encounters  between  the  military  vehicles  being 
simulated  in  a  scenario.  An  encounter,  in  this  context,  is  defined 
as  the  firing  of  one  or  more  OPFOR  or  friendly  force  weapon 
systems.  All  entities  with  weapon  systems  shall  be  able  to 
engage  any  other  entities  (enemy  vs  enemy,  friendly  vs  friendly, 
friendly  vs  enemy,  and  enemy  vs  friendly) .  Engagement  functional 
requirements  involve  five  basic  requirements.  First .  PLBS  should 
model  the  operational  characteristics  associated  with  the  use  of 
various  weapon  systems,  including  variables  such  as  reload  times. 
Second.  PLBS  should  model  the  potential  effects  resulting  from  the 
use  of  weapon  systems  including  vehicle/equipment/weapon  system 
damage  and  destruction.  Third .  the  effects,  if  any,  of  a 
successful  engagement  by  a  weapon  system  (i.e.,  a  hit)  must  be 
represented  to  the  different  PLBS  positions  (i.e.,  Controller, 
OPFOR,  and  TC‘s)  with  varying  degrees  of  specificity.  For  example, 
if  one  tank  engages  another  and  obtains  a  direct  hit,  the  tank  that 
was  hit  certainly  would  know  that  his  turret  is  no  longer 
functioning,  while  the  tank  firing  the  round  would  not  necessarily 
be  aware  of  this  fact.  Fourth .  the  detectable  events  and 
conditions  created  as  a  result  of  a  weapon  system  firing  (i.e., 
weapon  signature,  impact  of  munitions)  must  be  represented  to  the 
appropriate  PLBS  positions.  Fifth.  PLBS  must  maintain  an  audit  of 
the  amount  of  munitions  expended  by  each  friendly  weapon  system. 
PLBS  engagement  functional  requirements  can  be  specified  best  by 
addressing  each  of  the  following  individually: 


Weapon  Systems  Involved. 


TC  Controlled  Weapon  Systems. 


OPFOR  Controlled  Weapon  Systems. 


Weapon  Effects  Modeling. 


Representation  Requirements. 


One  of  the  most  critical  factors  or  variables  that  must  be 
considered  in  the  development  of  engagement  modeling  and 
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representation  processes  is  the  weapon  system  involved.  The  weapon 
systems  which  shall  be  modeled  in  PLBS  are  as  follows: 


Host  Weapon  Systems 

Trainee  Controlled:  ’ . 

Ml  Abrams  Tank  Main  Gun  (Heat  and  Sabot)  and  Coax 

Bradley  M2/3  TOW,  25mm  Chain  Gun 

OPFOR  Controlled: 

T72  Tank  Main  Gun  (Heat  and  Sabot) 

Friendly  Tank  Main  Gun  (Heat  and  Sabot) 

Enemy  PC  Sagger,  75mm  Main  Gun 

Enemy  Helicopter  Sagger,  25mm  Chain  Gun 

Friendly  Helicopter  TOW,  25mm  Chain  Gun 

Man-Packed  Sagger  Sagger 


The  Controller  shall  be  permitted,  at  initialization,  to 
specify  starting  loads  for  each  of  the  above  weapon  systems. 


Each  PLBS  TC  station  will  control  one  of  two  entities:  a  tank 
or  a  personnel  carrier  (PC) .  The  weapon  systems  of  each  will  be 
discussed  individually. 


Ml  Abrams  Tank  Weapon  Systems.  Each  PLBS  TC  position  shall 
have  total  control  of  the  weapon  systems  at  that  position.  An  Ml 
tank  has  four  weapon  systems  aboard:  the  tank  main  gun,  a  coaxial 
machinegun,  a  .50  caliber  machinegun,  and  the  loader's  7.62mm 


machinegun.  Only  the  main  gun  and  the  coaxial  machinegun  will  be 
simulated  in  PLBS. 


On  an  Ml  tank,  the  main  gun  and  coax  can  be  fired  by  either 
the  gunner  or  the  TC .  In  PLBS  only  the  gunner  will  be  permitted  to 
fire  the  main  gun  and  coax. 


Orientation  of  Ml  Abrams  Tank  Weapon  Systems.  The  TC  is 
responsible  for  the  rough  orientation  of  the  main  gun  and  the  coax 


PLBS  shall  provide  the  following  functions  associated  with  weapon 
system  orientation,  discussed  in  terms  of  direction,  rate,  control, 
and  perception: 


Direction  --  At  any  point,  the  TC  shall  be  able  to 
position  the  weapon  systems  in  any  direction,  given  that 
they  are  operational.  He  shall  be  able  to  do  this 
whether  the  tank  is  stationary  or  moving. 


Rate  --  The  speed  of  weapon  system  orientation  is  not  of 
great  concern  in  PLBS.  However,  it  shall  neither  require 
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a  great  deal  of  time  nor  occur  at  such  a  rapid  rate  that 
it  is  difficult  to  control. 

Control  —  The  mechanism  used  to  position  the  weapon 
systems  shall  be  a  joystick  like  device.  This  one  device 
shall  control  the  movement/orientation  of  the  turret  to 
which  both  weapon  systems  are  attached  (individual  weapon 
system  orientation  is  not  necessary) . 

Perception  —  Each  TC  shall  always  be  aware  of  the 
position  of  the  main  gun  and  coax  turret.  This  shall  be 
accomplished  by  extending  a  line  from  the  center  of  the 
graphic  tank  representation  in  the  direction  of 
orientation . 

Engaging  With  Ml  Abrams  Tank  Main  Gun  and  Coax.  In  a  real 
tank,  the  main  gun  and  coax  can  be  controlled  and  fired  by  either 
the  gunner  or  TC .  As  stated  previously,  in  PLBS,  the  TC  will  not 
be  permitted  to  actually  fire  either  of  these  weapon  systems. 
Instead,  the  TC  will  issue  fire  commands  to  his  crew  (simulated  or 
human) .  In  PLBS,  these  fire  commands  shall  be  handled  by  one  of 
two  methods  depending  upon  whether  computer  voice  recognition  is 
being  utilized.  If  voice  recognition  is  being  utitilized,  input  to 
PLBS  shall  be  via  voice.  If  not,  input  to  PLBS  shall  be  via  a 
keypad  device. 

In  both  the  one  and  two  person  modes  of  play,  when  computer 
voice  recognition  is  utilized,  the  TC  shall  issue  voice  gunnery 
commands,  through  his  intercom,  directly  to  the  computer.  In  the 
one  person  mode,  when  computer  voice  recognition  is  not  utilized, 
the  TC  shall  issue  gunnery  commands  by  selecting  a  command  on  the 
keypad.  In  the  two  person  mode,  when  computer  voice  recognition  is 
not  utilized,  the  TC  shall  issue  voice  gunnery  commands,  through 
his  intercom,  to  the  human  driver/gunner.  The  human  driver/gunner 
will  then  select  the  appropriate  command  on  the  keypad.  In  all 
modes  of  play,  the  crew  responses  to  gunnery  commands  shall  be 
accomplished  through  computer  voice  playback. 

Once  a  TC  has  identified  a  target  he  wishes  to  engage  with 
either  the  coax  or  the  main  gun,  PLBS  shall  first  allow  the  TC  to 
traverse  the  turret  so  that  the  main  gun,  and  coax  are  pointed  in 
the  general  direction  of  the  target.  Once  this  has  been 
accomplished,  PLBS  must  accommodate  a  series  of  gunnery  commands. 
The  sequence  of  commands  and  the  functional  requirements  related  to 
them  are  as  follows:1 


1  Fcr  explanatory  purposes,  gunnery  commands  are  described  assuming  either  the 
two  person  mode  or  the  one  person  mode  with  voice  recognition.  If  the  two 
person  mode  is  being  played  without  computer  voice  recognition,  the  human 
driver/gunner  will  select  the  appropriate  option  on  the  keypad.  If  the  one 
person  mode  is  being  played  without  computer  voice  recognition,  the  TC  will 
select  the  appropriate  option  on  the  keypad  instead  of  issuing  a  voice  command 
over  the  tank  intercom. 
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TC  Provides  Alert  to  Gunner  --  The  TC  will  call  out  "Gunner!" 
over  the  tank  intercom.  This  alert  normally  is  provided  at 
the  same  time  the  TC  is  traversing  the  turret  in  the  general 
direction  of  the  target.  The  purpose  of  the  command  is  to 
alert  the  gunner  that  the  TC  wants  him  to  engage  a  target. 

TC  Identifies  Weapon  System  to  Engage  --  The  gunner,  having 
been  alerted  that  he  should  prepare  to  engage  a  target,  now 
must  be  told  which  weapon  system  (coax  or  main  gun)  he  should 
use  to  engage  the  target.  If  the  TC  wants  the  gunner  to 
engage  the  target  with  the  coax,  the  TC ' s  next  command  over 
the  tank  intercom  will  be  simply,  "Coax!".  If  the  TC  wants 
the  gunner  to  engage  the  target  with  the  tank  main  gun,  the 
TC * s  next  command  over  the  tank  intercom  will  be  either 
"Heat!"  or  "Sabot!",  specifying  which  of  the  two  types  of  tank 
main  gun  rounds  should  be  used. 

TC  Describes  Target  --  The  TC  will  then  describe  over  the  tank 
intercom  the  target  to  be  engaged  (e.g.,  "Tank",  "PC", 

"Truck",  "Chopper") . 

For  explanitory  purposes,  gunnery  commands  are  described 
assuming  either  the  two  person  mode  or  the  one  person  mode  with 
voice  recognition.  If  the  two  person  mode  is  being  played  without 
computer  voice  recognition,  the  human  driver/gunner  will  select  the 
appropriate  option  on  the  keypad.  If  the  one  person  mode  is  being 
played  without  computer  voice  recognition,  the  TC  will  select  the 
appropriate  option  on  the  keypad  instead  of  issuing  a  voice  command 
over  the  tank  intercom. 

Loader  Announces  Message  —  After  the  appropriate  load  time 
delay,  the  loader  will  announce  "Up!"  when  the  round  has  been 
loaded.  PLBS  shall  provide  this  message  to  the  TC  over  the 
intercom.  Three  ammo  load  time  delays  shall  be  utilized:  "No 
Ammo  Loaded",  "Ammo  Already  Loaded"  and  "Wrong  Ammo  Loaded". 
These  time  delay  factors  shall  be  constants  specified  for 
each  weapon  system  for  which  they  apply,  and  shall  be 
modifiable  at  system  initialization  (see  section 
Initialization) . 

If  the  supply  of  ammunition  of  the  designated  type  is 
exhausted,  the  loader  will  announce  "Out  of  Ammo!"  and  the 
engagement  will  be  cancelled. 

If  the  supply  of  ammunition  of  the  designated  type  will 
fall  below  the  alert  level  specified  at  initialization  (see 
section  Initialization),  after  firing  the  round  the  loader 
shall  announce  "Up  -  Running  Low!". 

Gunner  Announces  Message  --  Once  the  simulated  gunner  has 
identified  the  target,  PLBS  must  then  provide  the  message 
"Identified!"  from  the  gunner  to  the  TC  (over  the  intercom). 
The  process  by  which  the  gunner  (PLBS)  identifies  a  target 
shall  be  as  follows: 
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If  only  one  entity  of  the  announced  target  type 
exists  within  "n"  number  of  degrees  of  the  turret 
orientation  by  the  TC,  the  gunner  refines  the  placement  of 
the  gun  tube  directly  on  the  identified  target,  and 
announces  "Identified!". 

If  more  than  one  entity  of  the  announced  target  type 
exists  within  "n"  number  of  degrees  of  the  turret 
orientation  by  the  TC,  the  gunner  determines  which  of  the 
specified  target  type  entities  is  closest  to  the  TC ' s 
orientation  of  the  turret.  If  two  entities  are  within  "x" 
degrees  of  the  TC ' s  orientation  of  the  turret,  the  Gunner 
selects  the  one  which  is  closest  to  his  vehicle.  He  then 
refines  the  placement  of  the  gun  tube  directly  on  the 
identified  target,  and  announces  "Identified!". 

If  no  target  of  the  specified  target  type  exists 
within  "n"  degrees  of  the  turret  orientation  by  the  TC, 
the  gunner  announces  "Cannot  Identify!"  and  the  engagement 
will  be  cancelled.  The  number  of  degrees  (n)  in  the 
engagement  identification  area  as  well  as  the  number  of 
degrees  (x)  which  denotes  an  area  of  closest  target 
decision  shall  be  constants  which  are  modifiable  at  system 
initialization  (see  section  Initialization) . 

TC  Gives  Fire  Command  —  Once  the  loader  has  said  "Up"  and 
the  gunner  has  said  "Identified"  ,  the  TC  will  give  the 
command  "Fire!".  At  this  point,  PLBS  should  cause  the  tank 
main  gun  or  coax  (depending  on  the  weapon  system  specified  by 
the  TC  earlier)  to  fire. 

Gunner  Gives  Fire  Response  to  TC  —  If  the  tank  main  gun  is 
to  be  fired,  PLBS  must  output  the  message  "On  the  Way!"  from 
the  gunner  to  the  TC  over  the  intercom. 

Subsequent  Firing  Activity  —  If  the  Coax  is  being  fired, 
firing  will  cease  only  when  the  TC  issues  a  "Cease  Fire" 
command,  the  target  moves  out  of  line-of-sight ,  or  the  ammo 
is  exhausted.  If  the  ammo  runs  low,  the  loader  shall 
announce  "Low  On  Ammo!". 

If  the  tank  main  gun  is  being  fired,  the  gunner  will  have 
to  provide  feedback  to  the  TC .  This  feedback  will  vary 
depending  on  whether  or  not  the  target  was  hit,  as  in  the 
following  situations: 

If  the  target  was  hit,  the  gunner  (i.e.,  PLBS)  will 
tell  the  TC  "Target  -  Re-engaging"  (over  the  intercom)  and 
will  continue  to  fire  until  the  target  moves  out  of 
line-of-sight,  the  TC  issues  a  "Cease  Fire"  command  or  the 
ammo  is  exahausted  or  the  target  is  destroyed.  If  the 
ammo  runs  low,  the  loader  shall  announce  "Low  On  Ammo!". 

If  the  target  was  missed,  the  gunner  (i.e.,  PLBS) 
will  tell  the  TC  "Re-engaging."  Given  that  the  gunner 
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will  always  be  presumed  to  have  seen  the  target  and  the 
relationship  of  the  target  to  the  area  where  his  missed 
round  impacted,  the  gunner  will  fire  automatically  at  the 
target  once  again.  This  will  continue  until  the  target  is 
hit,  moves  out  of  line-of-sight  or  the  TC  issues  a  ’’Cease 
Fire".  If  the  ammo  runs  low,  the  loader  shall  announce 
"Low  On  Ammo!". 

Control  of  the  coaxial  machinegun  spray,  or  area  of  coverage, 
shall  be  a  constant  specified  at  initialization  as  a  number  of 
degrees.  The  degrees  shall  represent  the  offset  from  the  coax 
machinegun  orientation  in  both  a  clockwise  and  a  counter-clockwise 
direction  which  the  machinegun  shall  spray. 

Bradley  M2/3  Weapon  Systems.  PLBS  shall  simulate  the  TOW  and 
25mm  Chain  Gun  of  the  PC.  The  gunner  (simulated)  shall  actually 
fire  these  two  weapons  upon  receiving  commands  from  the  vehicle 
commander . 

Orientation  of  Bradley  M2/3  Weapon  Systems.  It  is  the 
responsibility  of  the  vehicle  commander  to  roughly  position  the 
orientation  of  the  TOW  and  25mm  Chain  Gun.  For  this  reason,  PLBS 
shall  provide  the  following  functions  associated  with  weapon  system 
orientation,  discussed  in  terms  of  direction,  rate,  control,  and 
perception : 

Direction  —  At  any  point,  the  TC  shall  be  able  to  position 
the  weapon  systems  in  any  direction,  given  that  they  are 
operational.  He  shall  be  able  to  do  this  whether  the  vehicle 
is  stationary  or  moving. 

Rate  —  The  speed  of  weapon  system  orientation  is  not  of  great 
concern  in  PLBS.  However,  it  shall  neither  require  a  great 
deal  of  time  nor  occur  at  such  a  rapid  rate  that  it  is 
difficult  to  control. 

Control  —  The  mechanism  used  to  position  the  weapon  systems 
shall  be  a  joystick  like  device.  This  one  device  shall 
control  the  movement/orientation  of  the  turret  to  which  both 
weapon  systems  are  attached  (individual  weapon  system 
orientation  is  not  necessary) . 

Perception  —  Each  TC  shall  always  be  aware  of  the  position  of 
their  TOW  and  25mm  Chain  Gun.  This  shall  be  accomplished  by 
extending  a  line  from  the  center  of  the  graphic  PC 
representation  in  the  direction  of  orientation. 

Engaging  With  Bradley  M2/3  TOW  and  25mm  Chain  Gun.  The 
vehicle  commander  will  not  be  permitted  to  actually  fire  either  the 
TOW  or  the  25mm  chain  gun.  Instead,  the  vehicle  commander  will 
issue  fire  commands  to  his  crew  (simulated  or  human) .  In  PLBS, 
these  commands  shall  be  handled  by  one  of  two  methods  depending 
upon  whether  computer  voice  recognition  is  being  utilized.  If 
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voice  recognition  is  being  utilized,  input  to  PLBS  shall  be  via 
voice.  If  not,  input  to  PLBS  shall  be  via  a  keypad  device. 

In  both  the  one  and  two  person  modes  of  play,  when  computer 
voice  recognition  is  utilized,  the  TC  shall  issue  voice  gunnery 
commands,  through  his  intercom,  directly  to  the  computer.  In  the 
one  person  mode,  when  computer  voice  recognition  is  not  utilized, 
the  TC  shall  issue  gunnery  commands  by  selecting  a  command  on  the 
keypad.  In  the  two  person  mode,  when  computer  voice  recognition  is 
not  utilized,  the  TC  shall  issue  voice  gunnery  commands,  through 
his  intercom,  to  the  human  dr iver/gunner .  The  human  driver/gunner 
will  then  select  the  appropriate  command  on  the  keypad.  In  all 
modes  of  play,  the  crew  responses  to  gunnery  commands  shall  be 
accomplished  through  computer  voice  playback. 

Once  a  TC  has  identified  a  target  he  wishes  to  engage  with 
either  the  the  TOW  or  the  25mm  chain  gun,  PLBS  shall  first  allow 
the  TC  to  traverse  the  turret  so  that  the  turret  is  pointed  in  the 
general  direction  of  the  target.  Once  this  has  been  accomplished, 
PLBS  must  accommodate  a  series  of  TC  gunnery  commands.  The 
sequence  of  commands  and  the  functional  requirements  related  to 
them  are  identical  to  the  requirements  stated  previously  for  the 
tank  main  gun  and  coax,  with  the  following  exceptions: 

When  the  vehicle  commander  wants  the  gunner  to  engage  the 
target  with  the  TOW,  his  command  over  the  intercom  will  be 
"Missile!".  If  the  vehicle  commander  wants  the  gunner  to 
engage  the  target  with  the  Chain  Gun,  the  command  will  be 
either  "AP ! "  or  "HE!". 

The  loader  shall  not  respond  with  "Up!"  for  the  PC  weapon 
systems . 

For  subsequent  firing  activity,  the  TOW  and  Chain  Gun  shall 
be  handled  in  the  same  manner  as  the  Ml  Abrams  Main  Gun. 

OP  FOR  ..Controlled  Weapon  Systems.  The  individual  occupying  the 
PLBS  OPFOR  position  will  be  provided  at  all  times  with 
representations  of  the  location  and  movement  of  all  OPFOR  vehicles 
as  specified  in  the  sections  on  PLBS  movement,  terrain  and 
detection/identification  functional  requirements.  It  is  this 
condition  that  dictates  most  of  the  functional  requirements 
associated  with  the  control  of  OPFOR  controlled  weapon  systems 
(which  differ  considerably  from  the  functional  requirements  for  TC 
weapon  system  control) . 

Or  1  e.nt  at  i  on  of  OPFOR  Controlled  Weapon  Systems.  PLBS  must 
provide  the  OPFOR  the  capability  of  either  not  controlling  the 
weapon  system  orientation  of  those  entities  which  he  is  controlling 
(both  friendly  and  OPFOR  forces)  or  allowing  PLBS  to  control  those 
weapon  system  orientations  automatically. 
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Weapon  system  orientation  for  OPFOR  controlled  entities  shall 
be  assumed  by  PLBS .  No  direct  user  control  is  necessary.  Weapon 
systems  shall  always  be  oriented  in  a  forward  direction  unless 
engaging.  When  a  entity  is  engaging,  the  weapon  system  shall  be 
oriented  in  the  direction  of  the  target. 

Engaging  with  OPFOR  Controlled  Weapon  Systems.  PLBS  must 
provide  the  OPFOR  the  capability  of  controlling  the  weapon  systems 
of  those  entities  which  is  controlling  (both  friendly  and  OPFOR 
forces ) . 

OPFOR  weapon  system  control  necessitates  the  following 
functional  requirements: 

Identification  of  Weapon  Platform  to  Use  —  Given  that  the 
OPFOR  will  have  represented  to  him,  at  all  times,  the 
location  of  all  his  weapon  system  platforms  (i.e.,  friendly 
and  enemy  PCs,  friendly  and  enemy  tanks,  friendly  and  enemy 
helicopters  and  enemy  man-packed  saggers)  as  well  as  anything 
detected  (i.e.,  potential  targets)  by  each  platform,  he  must 
have  the  ability  to  identify  which  weapon  platform  he  wishes 
to  fire. 

Identification  of  Weapon  System  —  As  stated  previously, 
several  weapon  platforms  will  be  controlled  by  the  OPFOR. 

Only  one  tank  weapon  system  (main  gun)  and  one  man-packed 
sagger  weapon  system  (sagger)  will  be  simulated.  Therefore, 
when  the  OPFOR  selects  one  of  these  entities  as  the  weapon 
platform  he  wishes  to  fire,  it  will  always  be  its  sole  weapon 
system  that  fires.  However,  should  the  OPFOR  select  a 
friendly  or  enemy  PC  helicopter  as  the  weapon  platform  to 
engage  a  target,  there  are  two  weapon  systems  that  could  fire 
for  each.  A  friendly  PC  could  fire  its  TOW  or  its  25mm  chain 
gun.  A  friendly  helicopter  could  fire  its  TOW  or  its  25mm 
chain  gun.  An  enemy  PC  could  fire  its  sagger  or  its  75mm 
Main  Gun.  An  enemy  helicopter  could  fire  its  sagger  or  its 
25mm  chain  gun.  Therefore,  whenever  the  OPFOR  identifies  one 
of  these  entities  as  the  weapon  platform  to  engage,  PLBS  must 
also  permit  him  to  select  which  weapon  system  he  wishes  to 
f  ire . 

Target  Identification  --  PLBS  shall  provide  the  OPFOR  a  means 
by  which  he  can  identify  the  intended  target.  This  means 
shall  be  a  crosshair  cursor  toggled  between  possible  targets. 
The  OPFOR  will  simply  toggle  the  crosshair  to  the  desired 
target  and  assign  it  by  selecting  the  accept  target  option. 

Fire  Command  --  After  selecting  the  weapon  platform,  the 
weapon  system  and  ammo  (if  necessary),  PLBS  shall  permit  the 
OPFOR  to  select  the  FIRE  option  to  initiate  the  engagement. 
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MgflPQn — Effects  Modeling.  When  one  or  more  weapon  systems 
engage  a  single  target,  PLBS  must  determine  the  effects  of  the 
weapon  system(s)  firing  on  the  target  engaged.  Two  subprocesses 
are  involved:  hit  probabilities  and,  if  the  target  is  hit, 
consequential  damage  to  the  target.  At  a  minimum,  hit 
probabilities  must  consider  the  following  variables: 

Distance  to  target. 

Type  of  target  (e.g.,  "hard",  "medium"  or  "soft"). 

Target  disposition  (e.g.,  stationary  or  moving). 

Firer  disposition  (e.g.,  stationary  or  moving) . 

After  having  determined  whether  or  not  the  target  was  hit, 

PLBS  must  next  determine  what  damage,  if  any,  the  target  suffered 
as  a  result.  It  should  not  be  assumed  that  a  target  is  destroyed 
anytime  it  is  hit.  Therefore,  PLBS  must  consider  the  following 
variables  to  determine  the  extent  of  damage  to  the  target  that  has 
been  hit : 

Type  of  impacting  munitions  (e.g.,  105mm  Heat,  25mm). 

Number  of  rounds  impacting  (e.g.,  first  or  subsequent  round). 

Target  vulnerability  (e.g.,  the  target's  mobility). 

Target  type  (e.g.,  type  of  armor,  wheeled,  or  tracked). 

Probabilities  of  "Hit"  and  subsequent  damage,  based  upon  the 
above  conditions  shall  be  specified  in  the  Conflict  Resolution 
Database  (CRD) .  The  CRD  shall  be  modifiable  at  system 
initializaton  (see  section  Initialization) . 

Representation  Requirements.  The  Controller,  the  OPFOR,  and 
all  TC ' s  shall  be  presented  with  visual  and  auditory 
representations  of  engagement  actions.  The  engagement 
representation  requirements  for  PLBS  fall  into  three  basic 
categories:  weapon  firing,  impact  of  weapon  rounds,  and  effect,  if 
any,  of  impacting  rounds.  Specifically,  these  requirements  dictate 
that  when  a  PLBS  entity  fires  a  weapon,  a  weapon  signature  shall  be 
displayed  upon  the  firing  entity  icon,  an  in-flight  representation 
shall  be  displayed  between  the  firer  and  the  target  icons,  and  an 
impacting  representation  shall  be  displayed  upon  or  around  the 
target  icon.  The  weapon  signature  and  the  in-flight  represent  at  ic  r. 
shall  differ  for  main  gun,  machinegun/cha in  gun  and  missile 
firings.  The  impacting  representation  shall  only  appear  if  an 
entity  is  hit.  When  an  entity  is  fired  upon  and  hit  by  direct 
fire,  the  station  controlling  this  entity  shall  be  presented  with 
an  auditory  cue . 
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INDIRECT  FIRE 

Dedicated  indirect  fire  support  will  be  provided  to  both 
friendly  and  OPFOR  forces  in  all  PLBS  scenarios.  To  satisfy  its 
indirect  fire  functional  requirements,  PLBS  must  maintain  a  record 
of  indirect  fire  allocations,  provide  a  means  for  both  the  friendly 
and  OPFOR  forces  to  request  indirect  fire  support,  deliver/impact 
indirect  fires,  and  represent  the  effects  of  indirect  fire  to  all 
PLBS  positions.  Each  of  these  requirements  will  be  discussed 
individually . 

Fire  Support.  Allocations 

No  weapon  system  found  on  the  battlefield  has  an  inexhaustable 
supply  of  munitions.  As  a  result,  friendly  force  indirect  fire 
weapon  system  usage  should  be  tempered  and  controlled.  For  this 
reason,  PLBS  shall  allow  for  the  allocation  of  munitions,  by  type, 
at  the  initialization  stage  of  a  PLBS  scenario.  When  the  supply, 
specified  at  initialization,  has  been  exhausted,  PLBS  will  notify 
the  Controller  by  an  alert  message  (see  section  Communication  for  a 
discussion  of  alert  message  requirements) .  Enemy  force  indirect 
fire  munitions  shall  be  inexhaustable. 

Friendly  Force  Indirect  Fire. .  Request s 

Armor  platoon  leaders  normally  request  indirect  fire  support 
in  one  of  two  ways:  either  by  direct  contact  with  a  Fire  Direction 
Center  (FDC)  using  formal  call  for  fire  procedures,  or  through 
communications  with  a  Fire  Support  Team  Forward  Observer  (FIST  FO) 
assigned  to  his  company  team.  In  the  latter  case,  formal  call  for 
fire  procedures  are  not  required  and  communications  are  not 
regimented  by  sequencing  or  content  protocols.  PLBS  will  not 
concern  itself  with  platoon  leader/FDC  calls  for  fire.  All 
indirect  fire  support  requests  will  be  handled  through 
communications  between  the  platoon  leader  and/or  the  platoon 
sergeant  and  a  FIST  FO. 

PLBS  shall  provide  for  three  (3)  munition  types:  High 
Explosive  (HE),  Scatterable  Mines,  and  Smoke;  three  (3)  mission 
types:  Spotting  Round,  Fire  For  Effect,  and  Final  Protective  Fire; 
and  three  (3)  target  location  methods:  Polar,  Grid,  and  Shift.  In 
addition  to  unit-based  target  identif icaton,  PLBS  shall  support 
target  reference  points  (TRP's)  as  a  reference  for  target  location. 
TRP ’ s  are  placed  and  named  during  initialization  (see  section 
Initialization)  . 

To  define  the  functional  requirements  associated  with  friendly 
force  indirect  fire  support,  two  areas  will  be  addressed.  The 
first  area  is  concerned  with  the  requirements  associated  with 
requesting  an  indirect  fire  mission.  The  second  is  the  manner  in 
which  the  requests  are  actually  processed. 

Indirect  Fire  Requests  —  When  either  the  platoon  leader  or 
the  platoon  sergeant  decides  to  request  an  indirect  fire 
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mission,  he  first  will  establish  contact  with  the  Company/ 
Team's  FIST  FO.  This  will  be  done  on  the  Company/Team  Net 
(see  section  Communication) .  The  role  of  the  FIST  FO  will  be 
assumed  by  the  PLBS  Controller. 

Given  that  the  Controller  may  assume  the  role  of  the  FIST 
FO,  it  will  be  his  responsibility  to  ensure  the  indirect  fire 
requests  received  from  the  platoon  leader  or  platoon  sergeant 
are  properly  processed. 

Request  Processing  --  Having  received  an  indirect  fire 
request  from  either  the  platoon  leader  or  platoon  sergeant, 
the  Controller  (acting  as  the  FIST  FO)  will  be  responsible 
for  actually  processing  the  request.  Therefore,  the 
Controller  must  be  able  to  specify  the  following  to  the 
system: 

Initial  Indirect  Fire  Request 

Mission  Number  —  Numeric  identifier  for  indirect  fire 
mission . 

Observer  or  Known  Point  Identification  —  Identification 
of  location  from  which  target  is  being  located  (platoon 
leader,  platoon  sergeant,  or  target  reference  point 
identifier  name) . 

Mission  Type  —  Spotting  round,  fire  for  effect,  or 
final  protective  fire. 

Method  of  Target  Location  —  Polar,  grid,  or  shift. 

Direction  and  Distance  —  In  mils  and  meters  (for  polar 
or  shift  calls);  or  UTM  locaton  (for  grid  calls). 

Target  Description  --  Optional  text  (used  only  in  post 
simulation  reports) . 

Munition  Type  --  High  explosive,  scatterable  mines,  or 
smoke . 

Time  on  Target  --  Time  delay  between  request  and  impact 
(minutes,  with  optional  default  set  at  initialization). 

Subsequent  Indirect  Fire  Adjustment 

Mission  Number  --  Numeric  identifier  for  indirect  fire 
mission. 

Mission  Type  --  Spotting  round,  fire  for  effect,  or 
final  protective  fire. 

Adjustment  -  Left/Right  and  meter  distance  and/or 
Add/Drop  and  meter  distance. 
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End  Indirect  Fire  Mission 

Mission  Number  -  Numeric  identifier  for  indirect  fire 
mission . 

It  is  not  being  suggested  that  formal  call  for  fire  procedures 
be  established  between  the  Controller  and  PLBS.  To  the  contrary, 
the  simplest  and  most  expedient  means  of  conveying  this  information 
to  PLBS  shall  be  used  to  avoid  overburdening  the  Controller.  To 
achieve  this,  the  use  of  "f ill-in-the-blank"  forms  and  menus  shall 
be  used. 

It  will  be  necessary  for  the  Controller  to  not  only  input 
initial  indirect  fire  requests,  but  also  to  input  adjustment 
requests  following  an  initial  request  for  fire  input  to  PLBS. 

PLBS  shall  allow  for  multiple  indirect  fire  missions  at  any 
given  time.  For  this  reason,  it  will  be  necessary  for  the 
Controller  to  specifiy  a  mission  number.  By  assigning  a  mission 
number  to  an  initial  indirect  fire  request,  the  Controller  will 
then  be  able  to  request  adjustments  with  a  minimum  of  data  input. 

Because  PLBS  shall  allow  both  initial  and  adjustment  calls  for 
fire,  the  Controller  must  be  provided  with  a  means  by  which  to  end 
an  indirect  fire  mission  in  order  to  indicate  that  no  additional 
adjustment  will  follow. 

The  number  of  salvos,  if  applicable,  for  all  friendly  force 
indirect  fire,  shall  be  identified  at  initialization  (see  section 
Initialization) . 

QPFQR  Indirect  Fire  Requests 

Given  that  there  are  no  training  objectives  associated  with 
the  OPFOR,  the  fidelity  of  the  procedures  associated  with 
requesting  indirect  fire  support  is  of  no  concern. 

In  addition,  because  there  is  concern  about  limiting  the 
procedural  burdens  placed  on  the  OPFOR,  the  manner  in  which  the 
OPFOR  requests  indirect  fire  support  will  differ  greatly  from  the 
way  the  friendly  forces  request  indirect  fire  support. 

The  individual  occupying  the  PLBS  OPFOR  position  should  not  be 
required  to  communicate  with  anyone  to  request  indirect  fire 
support.  Instead,  he  will  have  total  direct  control  over  the 
request  and  placement  of  indirect  fire.  The  OPFOR  shall  be 
provided  with  the  same  three  (3)  indirect  fire  options  as  the  TC ’ s : 
High  Explosive,  Scatterable  Mines,  and  Smoke.  Upon  selection  of 
one  of  these  options,  the  OPFOR  shall  then  be  prompted  to  select  a 
mission  type:  Spotting  Round,  Fire  For  Effect,  or  Rolling  Barrage 
Fire.  After  mission  type  selection,  the  OPFOR  shall  be  prompted  to 
place  his  crosshair  cursor  over  the  desired  impact  location  (two 
locations  for  Rolling  Barrage  Fire).  After  the  location (s)  have 
been  selected,  the  time  delay  between  an  OPFOR  request  for  indirect 
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fire  and  impact  shall  be  a  constant  delay  factor  designated  at 
initialization  (see  section  Initialization) .  The  number  of  salvos, 
if  applicable,  for  all  OPFOR  indirect  fire,  shall  be  identified  at 
initialization  (see  section  Initialization). 


Once  the  PLBS  system  has  received  an  indirect  fire  request 
(from  either  the  Controller  or  OPFOR),  it  must  process  the  request. 
Specifically,  these  functional  requirements  involve  the  following: 

Determining  the  eventual  impact  area  and  radius  of  effect  of 
the  requested  fire.  The  radius  of  effect  for  each  type  of 
indirect  fire  shall  be  modifiable  at  system  init ializaton  (see 
section  Initialization) . 

Given  the  aforementioned,  determining  which  of  the  OPFOR  and 
friendly  force  vehicles  should  be  provided  with  auditory 
and/or  visual  cues. 

Appropriate  timing  of  the  events  associated  with  an  indirect 
fire  request  (e.g.  time  from  shot  to  splash) . 

Providing  the  indirect  fire  requester  (i.e..  Controller  or 
OPFOR)  with  both  "Shot"  and  "Splash"  messages  at  the 
appropriate  times. 

Maintaining  a  count  of  the  number  of  rounds  (by  munition  type) 
expended  and  remaining  (for  friendly  force  only)  and,  when 
allocations  have  been  expended,  informing  the  Controller. 

Providing  the  appropriate  visual  and  auditory  cues  (discussed 
in  detail  in  the  next  section) . 

Assessing  the  effects,  if  any,  on  targets  located  in  the 
impact  area  and  providing  appropriate  cues  accordingly.  The 
various  damage  probabilities  for  each  type  of  indirect  fire, 
for  each  type  of  target,  shall  be  modifiable  at  system 
initialization  (see  section  Initialization)  . 

If  Scatterable  Mines  are  placed,  the  terrain  they  occupy  will 
become  and  remain  active  explosive  areas. 

If  Smoke  is  placed,  it  shall  remain  active  unitl  the  specified 
time  has  elapsed.  The  time  delay  before  smoke  dissipates 
shall  be  specified  at  intializaton . 


Impacting  fire  may  result  in  a  requirement  for  PLBS  to 
represent  either  a  visual  or  auditory  cue,  or  possibly  both,  to 
PLBS  positions.  The  criteria  regarding  what  would  be  represented 
should  consider  the  same  factors  discussed  in  detail  in  the  section 
on  the  PLBS  detection/identification  functional  requirements. 


As  stated  previously,  once  PLBS  has  determined  where  indirect 
fire  should  impact  and  has  determined  who  or  what  can  detect  the 
impacting  fire,  PLBS  must  represent  the  appropriate  cues  to  certain 
PLBS  positions  (if  detected,  identification  is  100%) •  Each  mission 
type  and  munition  type  shall  be  represented  in  a  unique  manner. 

The  mission  types  shall  be  visually  represented  by  one  or  more 
graphic  icons  respresent ing  either  one  (single  round)  or  several 
(battery  or  rolling  barrage)  rounds.  Three  graphic  icons  shall  be 
used,  one  each  for  High  Explosive,  Scatterable  Mines,  and  Smoke. 

If  an  entity  is  hit  by  indirect  fire,  the  station  controlling  that 
entity  shall  be  presented  with  an  auditory  cue. 


COMMUNICATION 

The  communication  functional  requirements  for  PLBS  serve  three 
primary  purposes.  First,  they  will  permit  the  Controller  to 
interact  with  other  PLBS  positions  in  order  to  control  the 
simulation.  Second,  they  will  permit  Controller  to  monitor 
tactically  related  communications  for  evaluation  and  feedback 
purposes.  Third,  they  will  provide  PLBS  TC ' s  with  a  realistic 
tactical  communications  environment.  Realism  in  this  context  means 
that  the  communication  networks,  the  participants  in  those  networks 
(i.e.,  PLBS  positions  and  roles  simulated  by  PLBS),  and  the  means 
of  communicating  found  in  field  tactical  environments  will  be 
represented  in  PLBS.  Communication  functional  requirements  are 
divided  into  the  following  subsections: 

Communication  Network  Participants. 

Communication  Networks. 

Communication  Network  Selection. 

Communication  Network  Jamming. 

Communication  Network  Recording. 

Hand  and  Arm  Signals. 

Textual  Message  Transfer/Alerts. 

Communictation  Network  Participants 

To  understand  the  communication  requirements  for  PLBS,  it  is 
first  necessary  to  know  what  positions  or  roles  will  be 
communicating  in  each  network  as  well  as  who  or  what  will  be 
assuming  these  roles.  There  are  seven  positions  involved  in  the 
communication  networks  required  by  PLBS.  Specifically,  the 
positions  involved  and  whoever  or  whatever  will  assume  these 
participatory  roles  are  as  follows: 


TC ' s  --  These  include  the  platoon  leader,  platoon  sergeant, 
wingman-1  and  wingman-2 .  The  communication  requirements  of 


these  individuals  will  be  restricted  to  those  normally 
associated  with  their  positions  in  a  tactical  situation. 


Controller  --  The  Controller  will  have  the  ability  to 
communicate  with  all  TC ' s  (individually  and  collectively). 

OPFOR  —  The  individual  playing  the  role  of  the  OPFOR  can 
control  both  friendly  and  enemy  forces.  For  this  reason  he 
must  have  the  ability  to  communicate  with  other  members  of  the 
friendly  force.  In  addition,  the  OPFOR  must  be  able  to 
communicate  with  the  Controller  for  simulation  control 
purposes . 

Tank  Driver  —  The  tank  driver  of  concern  here  is  the  driver 
of  the  tank  controlled  by  each  TC,  but  not  the  driver  of 
any  tank  controlled  by  the  OPFOR.  The  driver  of  a 
TC  controlled  tank  will  be  either  a  human  driver  or  a 
simulated,  computer-controlled  role  capable  of  recognizing  TC 
driving  commands  (voice  or  joystick;  related  to  direction  and 
rate  of  movement) .  Specific  requirements  of  this  role  are 
addressed  in  detail  in  the  section  of  the  movement  functional 
requirements  for  PLBS. 

Gunner /Loader  --  The  gunner/loader  of  concern  here  is  the 
gunner/loader  of  the  tank  controlled  by  each  TC,  but  not 
the  gunner/loader  of  any  tank  controlled  by  the  OPFOR.  The 
gunner/loader  of  a  TC  controlled  tank  will  be  a  simulated, 
computer-controlled  role  capable  of  recognizing  firing 
commands  and  able  to  produce  minimal  voice  outputs  (i.e., 
"Identified"  and  "Up") .  Specific  voice  input/output 
requirements  are  addressed  in  detail  in  the  discussion  of  the 
engagement  functional  requirements  for  PLBS. 

FIST  FO  —  The  role  of  the  FIST  FO  will  be  assumed  by  the 
Controller  in  the  required  communication  network.  The 
function  of  this  role  will  be  to  receive  and  process  indirect 
fire  requests  from  the  friendly  force  platoon  leader  and/or 
platoon  sergeant . 

Company/Team  Leader  --  The  role  of  the  friendly  force 
company/team  leader  will  be  assumed  by  the  Controller.  The 
function  of  this  role  will  be  to  provide  normal  company/team 
leader  communications  to  the  friendly  force  platoon  leader 
and/or  platoon  sergeant  and  possibly  to  the  OPFOR  controlling 
friendly  forces. 

Cc-r.runlcation  Networks 

For  the  purpose  of  this  discussion,  communication  networks  or 
nets  will  be  discussed  in  terms  of  the  participants  who  are  to  be 
provided  with  a  capability  to  communicate  with  one  another  on  the 
net  and  the  purpose  that  the  net  is  intended  to  serve.  PLBS 
requires  three  communication  nets:  Platoon,  Company/Team,  and 
Intercom . 
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The  purposes  of  the  four  main  communication  nets  are  as 
f ol lows : 

Platoon  —  Tactical  operations  net  used  by  all  members  of  a 
platoon  (i.e.,  TC's)  for  functions. 

Company/Team  --  Tactical  operations  net  enabling 
communications  between  all  vehicles  of  the  company  team.  The 
primary  purpose  of  this  net  for  PLBS  is  to  enable  the 
Controller  to  role  play  a  company  team  leader  and  FIST  FO, 
thus  providing  the  necessary  interface  in  these  roles  with 
the  platoon  leader  and/or  platoon  sergeant  and  possibly  the 
OPFOR  controlling  friendly  forces. 

Intercom  —  Involves  satisfying  communication  requirements 
among  each  tank  driver,  gunner/loader  and  TC .  The  primary 
purpose  of  this  net  in  PLBS  is  control  of  movement  and  fire. 

Communication  Network  Selection 

TC's.  PLBS  TC's  shall  have  the  capability  of  selecting  and 
then  transmitting  and/or  receiving  on  different  communication  nets. 
Therefore,  each  of  these  individuals  must  be  provided  with  a  means 
of  selecting  the  communication  net  in  which  he  wishes  to  transmit 
and/or  receive/monitor. 
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Each  TC  shall  be  able  to  select  and  then  access  one  of  three 
PLBS  nets:  Platoon  Net,  Company/Team  Net,  or  their  individual 
Intercom  Net.  Specifically,  their  communication  net  selection 
requirements  dictate  that  they  have  the  capability  to: 

Simultaneously  monitor  both  the  Company/Team  and  Platoon 

Nets . 

Monitor  and  transmit  on  the  Company/Team  Net. 

Monitor  and  transmit  on  the  Platoon  Net. 

Hear  and  talk  on  the  Intercom  Net. 

They  should  not  be  permitted  to  transmit  on  more  than  one  net 

at  any  given  time. 

At  the  TC  stations  the  speaker  and  microphone  utilized  to 
communicate  over  the  various  networks  shall  be  those  which  are 
provided  in  the  government  furnished  Combat  Vehicle  Crewman  (CVM) 
helmets.  The  communications  control  device  used  shall  be 
government  furnished  C2298/VRC  control  boxes.  Two  helmets  and  two 
control  boxes  shall  be  available  at  each  TC  station.  One  for  the 
TC  and  one  for  the  human  crew  member  (if  present) . 

On  the  Intercom  Net  the  TC  shall  be  capable  of  talking  to  and 
hearing  the  simulated  crew  and  the  human  crew  member  (if  present) 
simultaneously.  Each  of  the  two  control  boxes  at  every  TC  station 
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have  a  five  (5)  position  selector  (ALL,  A,  INT  ONLY,  B,  C) .  The 
TC ’ s  control  box  shall  be  utilized  to  select  between  the  following 
network  capabilities: 


l. 


ALL  Monitor  and  transmit  on  the  Platoon  Net,  monitor 

the  Company/Team  Net . 

A  Monitor  and  transmit  on  the  Platoon  Net . 

INT  ONLY  Hear  and  talk  on  the  Intercom  Net . 

B  Monitor  and  transmit  on  the  Company/Team  Net . 

C  Monitor  and  transmit  on  the  Company/Team  Net, 

monitor  the  Platoon  Net. 

The  TC ' s  control  box  shall  be  modified  to  contain  an 
additional  switch.  This  switch  shall  be  a  two  position  switch  to 
control  the  destination  of  communications  over  the  Intercom  Net. 

In  one  position,  TC  communications  over  the  Intercom  shall  be 
routed  to  the  computer.  In  the  other  position,  TC  communications 
over  the  Intercom  shall  not  be  routed  to  the  computer. 

The  driver/gunner's  communications  control  box  shall  be  a 
dummy  box  which  provides  a  mount /connect ion  for  the  driver/gunner's 
CVC  helmet.  The  driver/gunner  shall  always  hear  exactly  what  the 
TC  hears  and  says  over  any  network. 

Controller .  The  Controller  net  selection  requirements  dictate 
that  P LBS  provide  the  Controller  with  the  capability  to: 

Simultaneously  monitor  the  Platoon  and  Company/Team  Nets. 

Simultaneously  transmit  over  the  Platoon  and  Company/Team 

Nets  . 

Monitor  and  transmit  on  the  Company/Team  Net . 

Monitor  and  transmit  on  the  Platoon  Net. 

The  Controller  shall  utilize  a  light-weight,  adjustable 
headset  with  earphone  speakers  and  a  microphone  along  with  a  foot 
pedal  to  activate  transmit  mode.  The  communications  control  shall 
be  provided  by  a  custom  designed  device  which  shall  be  utilized  to 
select  between  the  following  network  capabilities: 

ALL  Monitor  and  transmit  on  the  Platoon  and 

Company/Team  Nets. 


PLATOON 


COMPANY 


Monitor  the  Platoon  and  Company/Team  Nets  and 
transmit  on  the  Platoon  Net. 

Monitor  the  Platoon  and  Company/Team  Nets  and 
transmit  on  the  Company/Team  Net . 
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QPFQR .  The  OP FOR  will  be  controlling  not  only  enemy  force 
entities,  but  also  will  be  controlling  friendly  force  entities. 
For  this  reason,  the  OPFOR  must  be  allowed  to  communicate  on  the 
friendly  force  networks.  The  OPFOR  shall  have  the  capability  of 
selecting  and  then  transmitting  and/or  receiving  on  different 
communication  nets.  Therefore,  the  OPFOR  must  be  provided  with  a 
means  of  selecting  the  communication  net  on  which  he  wishes  to 
transmit  and/or  receive/monitor. 


The  OPFOR  shall  be  able  to  select  and  then  access  one  of  two 
PLBS  nets:  Platoon  Net  and  Company/Team  Net.  Specif ically,  the 
OPFOR  communication  net  selection  requirements  dictate  the 
following : 

Simultaneously  monitor  both  the  Company/Team  and  Platoon  Nets. 

Monitor  and  transmit  on  the  Company/Team  Net. 

Monitor  and  transmit  on  the  Platoon  Net. 

The  OPFOR  shall  not  be  permitted  to  transmit  on  more  than  one 

net  at  any  given  time. 

The  OPFOR  shall  utilize  a  light-weight,  adjustable  headset 
with  earphone  speakers  and  a  microphone  along  with  a  foot  pedal  to 
activate  transmit  mode. 


The  communications  control  device  used  shall  be  a  government 
furnished  C2298/VRC  control  box.  The  control  box  has  a  five  (5) 
position  selector  (ALL,  A,  INT  ONLY,  B,  C)  which  shall  be  utilized 
to  select  between  the  following  network  capabilities: 


ALL 


A 

INT  ONLY 

B 

C 


Monitor  and  transmit  on  the  Platoon  Net,  monitor 
the  Company/Team  Net . 

Monitor  and  transmit  on  the  Platoon  Net. 

Not  used. 

Monitor  and  transmit  on  the  Company/Team  Net . 

Monitor  and  transmit  on  the  Company/Net,  monitor 
the  Platoon  Net . 


Communication  Network  Jamming 

Electronic  Warfare  (EW)  is  a  very  real  threat  on  the  modern 
battlefield  and  will  be  experienced  at  all  Army  echelons  in  combat. 
Therefore,  jamming  of  PLBS  communication  networks  is  a  requirement . 
The  communication  jamming  functional  requirements  are  as  follows: 

All  jamming  will  be  controlled  by  the  Controller. 
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The  Controller  shall  be  provided  with  the  ability  to  select 
the  PLBS  communication  network  to  be  jammed  (selection 
alternatives  are  restricted  to  the  Platoon  and  Company/Team 
Nets) . 


The  Controller  must  have  the  ability  both  to  initiate  and 
terminate  the  jamming  of  a  net . 


Although  jamming  can  manifest  itself  on  a  radio  net  in  a 
variety  of  ways,  (e.g.,  gulls,  white  noise,  wobbler,  stepped 
tones)  PLBS  shall  simulate  only  white  noise. 


Jamming  shall  be  accomplished  by  selecting  the  network  to  be 
jammed  (Company/Team  and/or  Platoon)  and  the  desired  noise  volume 
on  the  Controller’s  communication  control  device.  The  maximum 
white  noise  volume  shall  be  well  within  comfortable  human  noise 
range.  To  eliminate  white  noise,  the  volume  dial  shall  be  turned 
off  . 


The  PLBS  communication  system  must  provide  a  means  by  which 
the  Company/Team  and  Platoon  networks  can  be  recorded  for 
subsequent  playback.  For  this  reason,  the  Controller’s 
communication  control  box  shall  provide  a  jack  for  simultaneous 
recording  of  the  Company/Team  and  Platoon  networks.  See  section 
Post-Simulation  for  further  details  on  network  recording  functional 
requirements . 


When  tank  platoons  are  involved  in  offensive  operations,  hand 
and  arm  signals  are  often  used  for  tank  platoon  communications. 
Although  they  may  occur  less  frequently,  they  are  also  used  by  tank 
platoons  in  defensive  operations.  Given  their  frequency  and  the 
ever  present  need  for  secure  communication  networks,  PLBS  shall 
permit  and  facilitate  the  use  of  hand  and  arm  signals. 

Specifically,  PLBS  shall  provide  each  of  the  TC  positions  with  the 
ability  to: 


Choose  the  hand  and  arm  signal  he  wishes  to  send. 


Send  a  selected  hand  and  arm  signal 


Receive  hand  and  arm  signals. 


Recognize  or  determine  from  whom  the  hand  and  arm  signal  is 
coming . 


The  graphic  representation  of  hand  and  arm  signals  shall 
include  a  large  hand  and  arm  signal  icon  displayed  in  an  upper 
corner  of  the  screen,  and  a  designator  on  the  sending  unit.  This 
display  shall  last  for  a  pre-specif ied  amount  time.  The  hand  and 
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arm  signal  display  time  factor  shall  be  a  constant  modifiable  at 
initialization  (see  section  Initialization). 

The  following  hand  and  arm  signals  shall  be  incorporated  in  PLBS: 


Wedge.  Travelling. 

Line.  Travelling  Overwatch. 

Vee .  Contact  Right. 

Herringbone.  Contact  Left. 

Coil.  Staggered  Column. 

Bounding  Overwatch.  Column. 

Echelon  Left.  Echelon  Right. 

Textual  Message  Transfer /Alert. s 

The  Controller  and  the  TC ' s  shall  be  provided  a  means  by  which 
they  can  communicate  typed  textual  messages. 

The  Controller  shall  be  allowed  to  select  one  to  four  TC 
stations  to  which  he  wishes  to  send  a  textual  message.  After 
selecting  the  desired  station  (s),  the  Controller  shall  then  be 
prompted  to  enter  an  eighty  character  or  less  message.  The  message 
shall  then  be  transmitted  to  each  of  the  selected  TC  stations. 

Upon  arrival  at  a  TC  station,  a  Controller  sent  message  shall  cause 
an  alert  to  be  signified  to  the  TC .  An  alert  shall  consist  of  both 
an  auditory  cue  and  a  graphic  symbol  on  his  display  which  informs 
him  that  a  message  is  awaiting  his  review.  To  review  pending 
messages,  the  TC  shall  be  allowed  to  select  the  display  of  his 
informational/status  window.  This  window  shall  be  displayed  on  the 
TC's  screen  until  he  selects  the  option  for  it  to  be  erased.  Once 
viewed,  the  message  shall  be  cleared  from  the  alert  queue. 

Each  TC  shall  be  allowed  to  select  from  among  five  (5) 
pre-defined  messages  to  send  to  the  Controller.  These  messages 
shall  be  defined  at  initialization  (see  section  Initialization) . 

To  send  a  pre-defined  message,  the  TC  shall  be  allowed  to  select 
the  "Send  Message"  option.  After  selection  of  this  option,  the  TC 
shall  be  prompted  to  select  from  among  the  five  (5)  pre-defined 
messages.  Once  selected,  the  message  shall  then  be  transmitted  to 
the  Controller  station.  Upon  arrival  the  message  shall  cause  an 
alert  to  be  signified  to  the  Controller.  An  alert  shall  consist  of 
both  an  auditory  cue  and  the  text  "ALERT  PENDING"  displayed  on  his 
monochrome  monitor.  To  review  pending  alerts,  the  Controller  shall 
be  allowed  to  select  a  display  of  alerts.  The  display  on  his 
monochrome  monitor  will  then  be  updated  to  display  all  pending 
alerts  along  with  an  identifier  for  the  initiator  of  each  alert. 
Upon  exiting  this  display,  all  pending  alerts  shall  be  emptied  from 
the  alerts  queue. 


Other  alerts,  such  as  low  ammunition  or  fuel  levels  (for  TC 
vehicles),  shall  be  queued  and  displayed  by  the  above  described 
method.  These  alerts  shall  be  automatically  sent,  at  the 
appropriate  times,  to  the  Controller  and  the  appropriate  TC . 

All  alerts/messages  shall  be  recorded  in  the  simulation 
history  for  subsequent  reporting  purposes. 

RESOURCES  AUDIT 

More  often  than  not,  events  on  a  battlefield  are  a  function  of 
the  resources  (e.g.,  weapons,  food,  fuel)  available  to  the 
combatants  involved.  These  resources  are  not  inexhaustable  and, 
once  expended,  can  change  the  course  of  a  battle.  The  resources  of 
concern  to  a  military  leader  vary,  depending  primarily  on  variables 
such  as  time  and  distances  involved. 

PLBS  must  be  sensitive  to  resources  critical  to  the  scenarios 
it  will  simulate.  Therefore,  PLBS  shall  maintain  an  audit  of 
friendly  force  resources  (i.e.,  what  they  started  with,  what  has 
been  expended,  what  remains,  and  when  a  resource  has  been 
exhausted) . 

An  inventory  of  possible  military  resources  would  be  an 
ambitious  undertaking  to  develop  as  well  as  to  reflect  in  the 
design  of  PLBS.  However,  as  stated  previously,  the  resources  about 
which  one  should  be  concerned  vary  depending  on  the  nature  of  the 
military  mission  (e.g.,  duration,  distances)  under  question.  In 
PLBS,  the  focus  will  be  on  armor  platoon  missions  or  operations 
involving  relatively  short  periods  of  time  and  short  traveling 
distances  (e.g.,  10  to  40  kilometers).  Therefore,  only  munitions 
(i.e.,  basic  loads  and  expenditures  of  weapon  systems  involved)  and 
fuel  resources  (i.e.,  fuel  capacities  and  fuel  consumption  rates  of 
vehicles  involved)  will  be  of  concern.  Each  of  these  resources  and 
their  resource  audit  functional  requirements  will  be  discussed 
individually . 


Although  fuel  resource  audit  functional  requirements  are 
critical  to  PLBS,  accurate  modeling  of  fuel  consumption  rules  does 
not  appear  to  be  sufficiently  important  to  warrant  extensive 
development  effort.  It  appears  sufficient  that  fuel  consumption  be 
computed  at  an  approximate  level.  The  following  are  the  PBLS  fuel 
resource  audit  requirements: 

PLBS  shall  maintain  an  audit  of  the  amount  of  fuel  used  by 
each  TC  vehicle  (non-TC  vehicle  fuel  shall  not  be  tracked) . 

Fuel  shall  be  consumed  at  a  constant  rate,  per  unit  of  time, 
(specified,  by  vehicle  type,  at  initialization)  while  an 
engine  is  running.  Fuel  shall  not  be  consumed  when  an  engine 
is  not  running.  Starting  or  initial  fuel  levels  for  each  TC 
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vehicle  shall  be  specified  at  initialization  by  the 
Controller . 

When  a  TC  vehicle  reaches  a  critical  fuel  level  (specified  at 
initialization)  or  when  all  fuel  is  exausted,  PLBS  shall 
inform  both  the  Controller  and  the  appropriate  TC  by  issuing 
an  alert  (see  section  Communication  for  a  description  of 
alerts) . 

Provide  a  record  at  the  conclusion  of  a  simulation  reflecting 
the  starting  fuel  level  as  well  as  the  amount  of  fuel 
expended  and  remaining  for  each  TC  vehicle  in  the  simulation. 

Munition  Resource  Audit  Requirements 

Given  that  each  TC  controlled  weapon  system  involved  in  a  PLBS 
scenario  will  have  been  identified,  along  with  starting  munition 
levels,  during  initialization,  PLBS  will  be  required  to: 

Maintain  an  audit  of  the  munition  expenditures  of  each  TC 
controlled  weapon  system  (i.e.,  rounds  fired  and  rounds 
remaining) . 

Inform  the  Controller  and  appropriate  TC  when  a  weapon  system 
has  reached  a  critical  ammo  level  or  has  exhausted  a  class  of 
munitions,  by  issuing  an  alert  to  the  appropriate  stations 
(see  section  Communication  for  a  description  of  alerts) . 

Provide  a  record  at  the  conclusion  of  a  simulation  reflecting 
the  amount  and,  if  appropriate,  type  of  munitions  expended 
and  remaining,  as  well  as  the  starting  levels,  for  each  TC 
controlled  weapon  system  in  the  simulation. 

Resupply 

Since  fuel  and  munitions  for  TC  vehicles  are  limited,  and  can 
therefore  be  exhausted,  a  means  must  be  provide  for  the  resupply  of 
these  elements.  PLBS  shall  allow  the  Controller,  through  a 
menu-option,  to  resupply  a  TC  vehicle  with  fuel  and/or  munitions. 
When  fuel  resupply  is  selected  for  a  particular  TC  vehicle,  that 
vehicle  shall  be  resupplied  with  a  previously  specified  amount  of 
fuel.  The  fuel  resupply  amount  shall  be  a  modifiable  constant 
specified  at  initialization.  When  munitions  resupply  is  selected 
for  a  particular  TC  vehicle,  the  weapon  system  and  munition  type 
must  be  specified.  The  vehicle  shall  then  be  resupplied  with  the 
previously  specified  amount  of  the  exhausted  munition  type.  The 
resupply  amount  for  each  vehicle,  by  weapon  system  and  ammuntion 
type,  shall  be  constants  modifiable  at  system  initialization. 


TIME 

As  a  battle  simulation  a  critical  function  of  PLBS  is  the 
representation  of  time.  Two  types  of  time  are  important:  real 
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time  and  simulation  time.  Each  of  these  will  be  defined  and 
discussed  separately;  information  regarding  the  functional 
requirements  related  to  simulation  time  will  then  follow. 


Real  time  refers  to  the  passing  of  time  in  the  "real  world” 
environment.  It  is  continuous  and  cannot  be  controlled.  It  can  be 
represented  by  a  clock  on  the  wall  and,  in  terms  of  this 
discussion,  it  is  external  to  PLBS .  Real  time  relates  solely  to 
"real  world"  considerations';  in  the  case  of  PLBS,  these 
considerations  relate  to  such  things  as  when  to  be  off  the 
simulator,  when  to  break  for  lunch,  or  how  long  it  takes  to 
complete  a  single  PLBS  scenario. 

Simulation  time,  on  the  other  hand,  refers  to  the  passage  of 
time  represented  in  PLBS ’ s  simulated  tactical  environment.  This 
passage  of  time  is  a  critical  factor  to  the  combatants  (i.e.,  OPFOR 
and  TC’s)  involved  in  the  tactical  situation.  In  such  an 
environment,  time  is  an  important  cue  to  the  existence  or 
nonexistence  of  an  expected  event.  For  example,  given  a  request 
for  indirect  fire,  the  requestor  expects  certain  events  at  certain 
times,  such  as  impacting  artillery.  Another  example  would  be  the 
expectation  of  a  platoon  leader  that  the  tanks  in  his  platoon  will 
simultaneously  begin  some  activity  at  a  specific  time.  Given  that 
the  Controller  controls  simulation  time,  OPFOR  and  TC 1 s  can  easily 
lose  track  of  time.  For  example,  if  they  expect  artillery  to 
impact  in  two  minutes  and  the  Controller  stops  the  simulation  for 
five  minutes  and  then  begins  it  again,  from  their  perspective,  did 
the  artillery  impact  three  minutes  ago  or  will  it  impact  in  two 
minutes? 


Given  that  PLBS  must  provide  all  simulation  positions  (i.e., 
TC’s,  OPFOR,  and  Controller)  with  some  perception  of  the  passage  of 
time  within  the  tactical  environment  being  simulated,  certain  PLBS 
simulation  time  functional  requirements  have  been  identified. 

Simulation  Time,  Requirements 


PLBS  must  permit  the  Controller  to  stop  a  simulation  at  any 
point  for  training  purposes  (e.g.,  to  point  out  an  error  made  by  a 
TC)  and/or  for  administrative  purposes.  In  addition,  the 
Controller  must  have  the  ability  to  replay  all  or  a  portion  of  a 
PLBS  simulation.  Normally,  this  will  be  done  at  the  conclusion  of 
a  simulation  to  show  PLBS  participants  what  occurred  and  to  permit 
the  Controller  to  review  the  just-completed  simulation  in  order  to 
determine  what  feedback  should  be  provided  to  the  TC ’ s . 


To  satisfy  these  processes,  there  are  several  time-control 
functional  requirements  PLBS  must  satisfy.  Specifically,  the 
Controller  must  be  capable  of: 


Specifying  a  specific  simulation  time  he  wishes  to  recall. 


Having  accessed  a  specific  simulation 
a  just-completed  simulation  where  the 


time  (i.e.,  a  point  in 
location  of  all 
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friendly  and  OPFOR  vehicles  are  shown) ,  accelerating  or 
slowing  down  (i.e.,  decelerating)  the  replay  of  the 
simulation  events  (either  forward  or  backward  in  time) . 

Stopping  or  freezing  in  place  an  in-process  simulation  or. 
replay  of  a  just-completed  simulation. 

Determining  the  simulation  time  (as  defined  previously)  in 
either  an  in-progress  simulation  or  a  replay  of  a 
just-completed  simulation. 

While  a  simulation  is  in  progress,  PLBS  must  allow  the 
Controller  to  note  simulation  times  related  to  critical  events  or 
conditions  that  he  may  want  to  recall  at  the  conclusion  of  the 
simulation.  This  capability  will  provide  the  Controller  an  easy 
and  expedient  means  of  noting  points  in  the  simulation  (which  may 
prove  critical  to  feedback)  without  disrupting  the  flow  and, 
therefore,  the  fidelity  of  the  simulation. 

Time  Representation  Reqn  i  remenf-  g 

Simulation  time  shall  be  presented  at  the  Controller  station 
using  a  digital  time  display.  The  participants  must  be  made  aware 
of  the  following: 

1 

The  starting  of  time  —  Participants  must  be  made  aware  that 
simulation  time  has  started  (or  restarted  in  the  event  that 
simulation  time  has  been  stopped  by  the  Controller) . 

The  stopping  of  time  —  Participants  must  be  made  aware  that 
simulation  time  has  been  stopped  whenever  the  Controller 
decides  to  stop  it. 

The  resetting  of  time  —  If  the  Controller  decides  to  reset 
simulation  time  to  an  earlier  or  later  point,  the 
participants  must  be  made  aware  of  this  fact  and  must  be  told 
the  point  at  which  the  time  has  been  reset. 

The  above  requirement  shall  be  met  by  the  Controller.  He  will 
inform  all  participants,  over  the  communication  network,  that  the 
simulation  time  has  been  started,  restarted,  stopped  or  reset.  At 
the  Controller  station  the  display  of  simulation  time  shall  appear 
at  the  top  of  the  monochrome  monitor. 

Update  Cycle 

The  update  cycle  is  the  interval  at  which  simulation  data  is 
transferred  to  each  PLBS  position  to  keep  all  positions  current  in 
their  knowledge  of  all  appropriate  simulation  activities.  PLBS 
shall  maintain  an  update  cycle,  with  four  (4)  TC  and  ten  (10)  OPFOR 
controlled  entities  active  in  a  simulation  run,  of  as  close  to  one 
second  as  possible. 
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POST-SIMULATION 


PLBS  differs  from  a  highly  structured  procedural  or  part-task 
trainer  having  predetermined  conditions,  actions,  and  standards. 
Instead,  in  PLBS  only  the  initial  conditions  are  set.  As  a 
result,  a  multitude  of  events,  actions,  and  conditions  will  occur 
at  a  very  rapid  rate  during  the  course  of  any  single  PLBS  run. 

Added  to  this  is  the  fact  that  the  conditions,  events,  actions,  and 
outcomes  of  each  scenario  simulated  in  PLBS  will  be  unique,  making 
the  problem  of  "what"  feedback  to  provide  and  "how"  to  provide  it  a 
serious  issue.  These  conditions  dictate  that  PLBS  must  provide  the 
Controller  access  to  various  data  in  various  forms  (e.g.,  visual, 
audio,  hard  copy)  from  which  he  can  determine  what  feedback  to 
provide  the  TC's  and  how  to  provide  it.  The  requirements 
associated  with  providing  feedback  have  been  labeled 
post-simulation  functional  requirements. 

Post-simulation  functional  requirements  are  defined  as  the 
PLBS  processes  necessary  to  support  the  Controller  responsibility 
to  provide  feedback  to  TC's.  Post-simulation  functional 
requirements  fall  into  three  categories:  visual  playback,  audio  or 
communications  playback,  and  hard  copy  outputs. 


One  critical  aspect  of  providing  feedback  related  to  tactical 
environments  is  the  ability  to  reconstruct  events,  actions,  or 
conditions.  In  PLBS,  each  of  the  positions  involved  will  be 
provided  a  different  perspective  of  events  as  they  occur.  In 
addition,  as  the  information  processing  capabilities  of  each 
position  become  overloaded  during  a  simulation,  the  ability  of  the 
TC  to  recall  events,  conditions,  or  actions  accurately  will  be 
severly  limited.  Therefore,  PLBS  must  have  the  capability  to 
record  events,  conditions,  and  actions  as  they  occur.  This  recall 
requirement  of  PLBS,  coupled  with  the  need  to  reconstruct  events, 
conditions,  and  actions,  has  resulted  in  the  identification  of  the 
following  visual  playback  functional  requirements: 

The  Controller  shall  be  provided  with  an  option,  at 
initializaton,  to  set  "Data  Capture"  on  or  off.  If  "Data 
Capture"  is  set  on,  the  data  capture  interval  must  then  be 
set  (1  second  -  5  minutes) .  When  "Data  Capture”  is  on,  PLBS 
shall  take  a  snap  shot  of  the  entire  simulation  at  the  set 
interval.  These  snap  shots  shall  then  be  used  to  provide 
visual  playback. 

The  Controller  must  be  able  to  specify  a  simulation  time  in 
hours  and  minutes  (e.g.,  1  hour,  31  minutes)  and  have  PLP.S 
recall  the  situation  at  that  point  in  time  in  a 
just-completed  or  temporarily  halted  simulation. 

Given  a  simulation  time,  the  Controller  must  be  able  to 
specify  which  perspective  he  wishes  to  see  (i.e.,  whatever 
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was  seen  on  the  display  of  the  Controller,  OPFOR  or  any  one 
of  the  TC ' s ) . 


Given  a  simulation  time,  perspective  and  station  selection, 
the  Controller  must  have  the  ability  to  move  forward  or 
backward  at  either  an  accelerated  or  a  decelerated  rate. 

Audio  or  Communications  Playback  Requirements 

It  is  important  that,  at  the  conclusion  of  a  simulation,  the 
Controller  be  provided  the  ability  to  review  (prior  to  providing 
feedback  to  TC's)  and  reconstruct  (while  providing  feedback  to 
TC's)  communications  which  occurred  during  the  just-completed  or 
temporarily  halted  simulation.  This  need  dictates  that  PLBS  record 
communications  that  occurred  during  the  simulation  and  provide  the 
Controller  the  ability  to  access  and  recall  it.  Given  these 
Controller  feedback  requirements,  the  following  audio  or 
communications  post-simulation  functional  requirements  have  been 
identified : 

The  Controller  must  be  able  to  select  the  recording  option 
for  the  Company/Team  and  Platoon  nets. 


£ 


The  Controller  must  be  able  to  determine  where,  on  the 
recording,  he  needs  to  position  the  playback  to  hear  the 
activity  recorded  at  a  specific  simulation  time. 

The  playback  of  audio/communication  net  recordings  shall  be 
achieved  through  the  speaker  of  the  recording  device  and/or 
through  the  Controller's  headset. 

Hard  Copy  Output  Requirements 

Although  the  conditions,  events,  actions,  and  outcomes  of  each 
scenario  simulated  in  PLBS  will  be  unique,  it  can  be  anticipated 
that  certain  data  may  be  critical  when  providing  feedback  to  the 
TC's.  These  data  requirements  can  be  viewed  as  serving  two 
purposes.  First,  they  will  provide  the  Controller  with  clues  about 
both  good  and  poor  performance .  As  such,  the  data  could  prompt  the 
Controller  to  look  for  additional  information.  Suppose,  for 
example,  that  PLBS  provided  the  Controller  with  a  hard  copy  output 
outlining  when  (in  simulation  time)  each  friendly  vehicle  was 
destroyed  or  damaged  and  which  OPFOR  weapon  system  caused  the 
destruction  or  damage.  The  Controller  could  use  this  data  to 
identify  the  visual  and  audio  or  communication  points  (i.e., 
simulation  time)  that  he  should  play  back  to  determine  what 
happened  and  what  feedback,  if  any,  should  be  provided.  The 
pre-determined  data  could  also  be  used  in  output  form  as  direct 
feedback  to  the  TC's,  thereby  providing  each  TC  with  a  listing  of 
the  number,  type  and  time  he  fired  main  gun  rounds  and  the  OPFOR 
casualties,  if  any,  that  resulted. 

The  post-simulation  hard  copy  outputs  for  PLBS  are  fall  into 
five  catagories:  general  simulation  summary,  friendly  force 
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summary,  direct  and  indirect  fire  utilization  summary,  and  vehicle 
path  summary.  Each  of  these  is  explained  below. 

General  Simulation  Summary  —  This  report  shall  provide  a 
general  summary  of  a  completed  simulation.  The  output  shall 
contain  the  date  and  identification  of  the  scenario  played, 
type  of  exercise  (platoon-level,  single  tank,  tank  section, 
or  company-team),  playing  time  (i.e.,  actual  time  required  to 
"play”  the  simulation),  simulation  time  (i.e.,  duration  of 
the  simulated  scenario) ,  and  names  of  the  individuals 
responsible  for  each  of  the  PLBS  positions.  A  sample  of  this 
output  is  shown  in  Figure  1. 

Friendly  Force  Summary  —  This  report  shall  consist  of  three 
sections:  mission,  resources,  and  damage/destruction.  The 
mission  section  shall  identify  the  friendly  force  mission  for 
the  scenario  played.  The  resources  section  shall  identify 
the  amount  of  direct  and  indirect  fire  allocated,  utilized, 
and  ending  amounts,  by  player  and  weapon  type/muniton  type. 
The  damage/destruction  section  of  this  report  shall  consist 
of  a  listing  of  each  player's  vehicle  along  with  any  damage 
received  during  the  scenario.  This  listing  shall  include  the 
simulation  time,  cause,  location  and  type  of  any 
damage/destruction.  This  report  shall  contain  a  header  which 
specifies  the  scenario  identification.  A  sample  of  this 
output  is  shown  in  Figure  2. 

Direct  and  Indirect  Fire  Utilization  Summary  —  This  report 
shall  consist  of  a  chronological  list  of  direct  and  indirect 
fire  utilization  by  type  (direct  or  indirect) .  This  list 
shall  include:  unit  identification  and  type  (firer  or 
requestor),  location  of  unit  (firer  or  requestor),  target 
identification  and  type,  location  of  target,  weapon 
munition  (s)  fired,  range  between  firer  and  target  (direct 
fire  only)  and  effects,  if  any,  of  fire.  This  report  shall 
contain  a  header  which  specifies  the  scenario 
identification.  A  sample  of  this  output  is  shown  in  Figure  3. 

Vehicle  Path  Summary  —  This  output  shall  be  a  scaled 
graphics  plot  of  the  path  one  or  more  player  vehicles 
followed  during  the  entire  simulation.  The  Controller  shall 
be  allowed  to  select  from  among  the  platoon  leader,  platoon 
sergeant,  wingman  #1  and/or  wingman  #2  to  be  included  in  a 
single  print  of  this  output.  This  output  shall  be  either 
printed  on,  or  transferable  to,  a  transparent  media  so  that 
it  may  be  overlayed  on  a  physical  map  of  the  simulation  area. 

At  the  end  of  a  simulation  run,  the  Controller  shall  be 
presented  with  the  following  three  options  for  each  report: 

Write  Report  to  File  Only  —  Selection  of  this  option  shall 
cause  PLBS  to  write  the  specified  report  to  disk  for  later 
review  and  printout. 


PLAYING  TIME  :  1  hr,  57  min 


SCENARIO  :  A- 04 


SIMULATION  TIME  :  1  hr,  3  min  DATE  :  17  DEC  8  6 

EXERCISE  TYPE  :  Platoon-Level 

PARTICIPANTS  : 

Controller  :  CPT  G.  L.  Smith  and  1LT  D.  D.  Boss 
OPFOR  Controller  :  1LT  D.  L.  Jones 
Platoon  Leader  :  2LT  J.  K.  Ogus 
2nd  Crew  Member  :  None 
Platoon  Sergeant  :  PSG  A.  D.  Killer 
2nd  Crew  Member  :  None 
Wingman  #1  :  SSG  A.  T.  Jeep 
2nd  Crew  Member  :  None 
Wingman  #2  :  SSG  H.  E.  Quick 
2nd  Crew  Member  :  None 


FIGURE  1.  Sample  General  Simulation  Summary 
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SCENARIO  :  A-04 


MISSION  :  Hasty  Defense 

RESOURCES : 


Direct  Fire 


Indirect  Fire 


SABOT  HEAT  _ 

-50  Cal 

7 . 62 

TfiH 

2  Sram 

HE 

Start 

PC 

42 

12 

1500 

500 

0 

0 

50 

PS 

42 

12 

5000 

8000 

0 

0 

0 

WM#1 

42 

12 

5000 

8000 

0 

0 

0 

WM#2 

42 

12 

5000 

8000 

0 

0 

0 

End 

PL 

32 

12 

1000 

1000 

0 

0 

30 

PS 

24 

6 

2000 

6000 

0 

0 

0 

WM#1 

20 

6 

1000 

2000 

0 

0 

0 

WM#2 

15 

4 

4000 

2000 

0 

0 

0 

Used 

PL 

10 

0 

500 

4000 

0 

0 

20 

PS 

18 

6 

3000 

2000 

0 

0 

0 

WM#1 

22 

6 

4000 

6000 

0 

0 

0 

WM#2 

27 

8 

1000 

6000 

0 

0 

0 

DAMAGE /DESTRUCTION : 

Time 

Cause 

HIM 

PL 

PS 

WM#1 

WM#2 

0110 

0111 

OPFOR-3  Tank 
OP FOR- 4  Tank 

Main 

Main 

Gun 

Gun 

123456 

123456 

Smnlcc  Mine 


15  5 

0  0 

0  0 

0  0 


15  0 

0  0 

0  0 

0  0 


0  5 

0  0 

0  0 

0  0 


Type  of  Kill 

Total 

Mobility 


FIGURE  2.  Sample  Friendly  Force  Summary. 


.'Cl* 


cl*. 


[•)< 


Uv1  V*»*v« 


SCENARIO  :  A-04 


CHRONOLOGICAL  LIST  OF  DIRECT  AND  INDIRECT  FIRE: 


rime* 

Type 

Unit 

CTM 

Target 

tJTM 

Haagaa  Range 

Effects 

3030 

Indirect 

OPFOR 

123456 

Arty/HE 

None 

3040 

Direct 

OP FOR - 
PC 

■1  123456 

PL 

123456 

Sagger 

2000 

None 

3045 

Direct 

PL 

123456 

OPFOR- 1 
PC 

123456 

Main  Gun 

2000 

None 

0046 

Direct 

WM#1 

123456 

OPFOR- 1 
PC 

123456 

Main  Gun 

2010 

Total 

0105 

Indirect 

PL 

123456 

Arty/HE 

OPFOR- 2 
PC 

Fire- 

Power 

0110 

Direct  OP FOR— 3 

123456 

PS 

123456 

Main  Gun 

1800 

Total 

Tank 


0111  Direct  OPFOR-4  123456  WM#1  123456  MainGun  1700  Mobility 
Tank 


*Simulation  Time 

FIGURE  3. Sample  Direct  and  Indirect  Fire  Utilization  Summary. 


Write  Report  to  Printer  Only  —  Selection  of  this  option 
shall  cause  PLBS  to  print  the  specified  report.  Later 
review  or  printout  of  this  report  shall  not  be  possible. 

Write  Report  to  File  and  Printer  —  Selection  of  this  option 
shall  cause  PLBS  to  write  the  specified  report  both  to  a 
disk  file  and  to  the  printer.  When  this  option  is  selected, 
later  review  and/or  printout  of  the  report  shall  be 
possible . 


STATUS  AND  INFORMATIONAL  DISPLAYS 

Each  PLBS  station  needs  to  be  informed  of  certain  events  and 
conditions  which  are  not  continuous  and  are  best  handled  by  special 
displays  of  information.  These  special  display  requirements  will 
be  discussed  in  terms  of  the  display  elements  required  for  each 
station. 

TC  Displays 

Each  of  the  TC  stations  shall  be  provided  with  the  following 
types  of  status  and  informational  displays: 

Engine  Status  and  Speed  —  the  presence  of  a  speed  indicator 
shall  mean  that  the  vehicle  engine  is  running;  its  absence 
means  that  the  vehicle  engine  is  not  running.  The  speed 
indicator  shall  be  a  number  representing  the  number  of 
kilometers  per  hour  at  which  the  vehicle  is  moving.  The 
speed  indicator  should  read  "0"  for  a  stationary  vehicle 
where  engine  is  running.  This  indicator  shall  always  be 
visable  if  the  vehicle's  engine  is  running. 

Alert  Cue  —  the  alert  cue  shall  be  displayed  on  the  TC • s 
screen  when  an  alert  (message  from  the  system) ,  or  a  message 
(from  the  Controller)  is  pending.  Until  the  alert  or  message 
has  been  viewed,  this  cue  shall  not  be  removed  from  the  TC ' s 
display . 

Send  Message  --  when  the  TC  selects  the  "Send  Message" 
option,  a  display  of  the  available  messages  (which  can  be 
sent  to  the  Controller)  shall  be  drawn  on  his  screen.  When 
he  selects  which  message  to  send  or  the  "CANCEL"  option,  this 
display  shall  be  erased. 

Special  Window  --  this  window  shall  be  displayed  when  the  TC 
selects  the  "Status  Window"  option,  and  shall  contain 
information  on  the  status  of  the  following  elements: 

Location  —  current  UTM  location  of  TC's  vehicle. 

Current  Fuel  Level  —  current  number  of  gallons  of  fuel 
remaining . 


Current  Munition  Levels  —  current  number  of  munitions 
remaining  by  weapon  and  ammo  type. 

Functionality  —  current  functional  status;  either  fully 
functional,  mobility  only  functional,  fire  power  only 
functional,  or  dead. 

Current  Terrain  Type  —  current  type  of  terrain  vehicle  is 
operating  within  (clear,  heavy  woods,  etc.). 

Alerts/Messages  —  display  of  any  pending  alerts  (sent  by 
system)  or  messages  (sent  by  Controller) . 

When  the  TC  selects  the  "Status  Window"  option  again,  the 
special  window  shall  be  erased. 

At  system  initialization,  the  Controller  shall  be  provided 
the  opportunity  to  select  whether  each  of  the  elements 
described  above  for  the  "Status  Window"  shall  be  displayed. 

QPFQR  Displays 

The  OPFOR  station  shall  be  provided  with  a  continuous  display 
of  information  on  his  monochrome  monitor.  This  display  shall  be 
updated,  if  necessary,  every  update  cycle.  The  information 
contained  in  this  display  shall  be  the  following: 

Entity  Status  —  for  each  OPFOR  controlled  entity,  the 
following  status  information  shall  be  displayed: 

Entity  ID  —  the  entity  identifier  or  name  and  type  of 
entity . 

Group  Affiliation  —  if  the  entity  is  grouped,  a  group 
identifier  shall  be  displayed. 

Forcasted  Path  Mode  —  if,  and  only  if,  the  entity  is 
moving  in  the  forcasted  route  mode,  an  indicator  to  that 
effect  shall  be  displayed. 

Functionality  —  current  functional  status;  either  fully 
functional,  mobility  only  functional,  fire  power  only 
functional,  or  dead. 

Current  Terrain  Type  --  current  type  of  terrain  entity  is 
operating  within  (clear,  heavy  woods,  etc.). 


Location  —  current  UTM  location  of  the  entity. 


Line-Of-Sight  —  if,  and  only  if,  the  entity  has 
line-of-sight  with  a  TC  vehicle,  an  indicator  to  that 
effect  shall  be  displayed. 


Entity  Speed  —  a  number  representing  the  number  of 
kilometers  per  hour  at  which  the  entity  is  moving. 

Controller  Displays 

One  of  the  Controller's  responsibilities  is  to  guide  and 
control  the  simulation.  To  do  this,  he  has  some  unique 
informational  display  requirements.  The  Controller  not  only  needs 
to  be  able  to  view  the  simulation  world  from  the  perspective  of  any 
one  of  the  simulated  entities,  he  also  needs  to  be  able  to  view  the 
simulation  environment  without  any  restrictions  what-so-ever 
(detection/identification  restrictions) ;  to  view  the  entire 
simulation  environment  and  all  of  its  on-going  activities.  To 
provide  the  Controller  with  this  ability,  he  must  be  allowed  to 
select  from  a  number  of  simulation  perspectives  (see  section 
Terrain  for  a  description  of  the  Controller's  possible  terrain 
perspectives).  The  Controller's  World  View  shall  be  the  method  by 
which  the  Controller  can  view  the  simulation  world  without 
restriction . 

With  this  perspective,  selected  simulation  entities,  events, 
and  conditions  shall  be  displayed  to  the  Controller  from  a 
"God's-eye"  perspective.  No  detection  or  identification 
restrictions  shall  be  placed  on  this  view.  The  Controller  shall  be 
allowed  to  interactively  select  the  desired  combination  of 
entities,  events,  and  conditions  which  he  desires  to  be  displayed 
at  this  view.  He  shall  be  allowed  to  clutter/declutter  his  display 
by  turning  on  and  off  the  display  of  the  following: 

All  TC  Controlled  Entites. 

All  OP FOR  Controlled  Enemy  Entities. 

All  OPFOR  Controlled  Friendly  Entities. 

Vehicle  Orientation. 

Turret  Orientation. 

All  TC  Controlled  Weapon  Signatures. 

All  OPFOR  Controlled  Enemy  Weapon  Signatures. 

All  OPFOR  Controlled  Friendly  Weapon  Signatures. 

All  Direct  Fire  Explosions  On  TC  Controlled  Entities. 

All  Direct  Fire  Explosions  On  OPFOR  Controlled  Enemy 

Entities  . 


All  Direct  Fire  Explosions  On  OPFOR  Controlled  Friendly 
Entities. 

Friendly  Indirect  Fire  Impacts. 

Enemy  Indirect  Fire  Impacts. 

Hand  and  Arm  Signals . 

Smoke . 

Terrain  Modifiers. 

Control  Measures. 

While  the  Controller  is  displaying  the  Controller's  World  View 
on  the  color  monitor,  the  monochrome  monitor  shall  display  the 
following  status  information: 

Indirect  Fire  —  remaining  friendly  force  indirect  fire 
allocations  by  munition  type. 

Simulation  Time  —  digital  reading  of  simulation  time  in 
hours  and  minutes. 

Entity  Status  —  for  each  simulation  entity,  the  following 
status  information  shall  be  displayed  (if  applicable) : 

Entity  ID  —  the  entity  identifier  or  name  and  type  of 
entity . 

Engine  Status  and  Speed  —  the  presence  of  a  speed 
indicator  shall  mean  that  the  vehicle  engine  is  running; 
its  absence  means  that  the  vehicle  engine  is  not  running. 
The  speed  indicator  shall  be  a  number  representing  the 
number  of  kilometers  per  hour  a  which  the  vehicle  is 
moving.  This  indicator  shall  always  be  visable  if  the 
vehicle  engine  is  running  (OPFOR  controlled  entity  engines 
are  always  running) . 

Current  Fuel  Level  • —  current  number  of  gallons  of  fuel 
remaining  (TC  vehicles  only) . 

Current  Munition  Levels  —  current  number  of  munitions 
remaining  by  weapon  and  ammo  type  (TC  vehicles  only) . 

Forcasted  Path  Mode  --  if,  and  only  if,  the  entity  is 
moving  in  the  forcasted  route  mode,  an  indicator  to  that 
effect  shall  be  displayed  in  the  special  window  (OPFOR 
entities  only) . 

Functionality  —  current  functional  status;  either  fully 
functional,  mobility  only  functional,  fire  power  only 
functional,  or  dead. 


Current  Terrain  Type  —  current  type  of  terrain  vehicle  is 
operating  within  (clear,  heavy  woods,  etc.). 

While  the  Controller  is  displaying  a  particular  entity 
perspective,  the  display  on  his  monochrome  monitor  shall  consist  of 
the  following  status  information: 

Simulation  Time  —  digital  reading  of  simulation  time  in 
hours  and  minutes. 

Entity  Status  —  for  the  entity  which  the  Controller  is 
viewing  the  perspective  of,  the  following  status  information 
shall  be  displayed  (if  applicable) : 

Entity  ID  —  the  entity  identifier  or  name  and  type  of 
entity . 

Engine  Status  and  Speed  —  the  presence  of  a  speed 
indicator  shall  mean  that  the  vehicle  engine  is  running; 
its  absence  means  that  the  vehicle  engine  is  not  running. 
The  speed  indicator  shall  be  a  number  representing  the 
number  of  kilometers  per  hour  at  which  the  vehicle  is 
moving.  This  indicator  shall  always  be  visable  if  the 
vehicle  is  running  (OPFOR  controlled  entity  engines  are 
always  running) . 

Current  Fuel  Level  —  current  number  of  gallons  of  fuel 
remaining  (TC  vehicles  only) . 

Current  Munition  Levels  —  current  number  of  munitions 
remaining  by  weapon  and  ammo  type  (TC  vehicles  only) . 

Forcasted  Path  Mode  —  if,  and  only  if,  the  entity  is 
moving  in  the  forcasted  route  mode,  an  indicator  to  that 
effect  shall  be  displayed  in  the  special  window.  (OPFOR 
entities  only) . 

Functionality  —  current  functional  status;  either  fully 
functional,  mobility  only  functional,  fire-power-only 
functional,  or  dead. 

Current  Terrain  Type  —  current  type  of  terrain  vehicle  is 
operating  within  (clear,  heavy  woods,  etc.). 

An  alert  cue  shall  be  displayed  on  the  Controller's  monochrome 
monitor,  independant  of  what  view  is  currently  displayed,  when  an 
alert  (message  from  the  system),  or  a  message  (from  one  of  the 
TC's)  is  pending.  This  alert  cue  shall  be  removed  after  the 
Controller  has  viewed  all  pending  alerts/messages. 


ENVIRONMENT 


Workstation  Cabinet  Requirements 

It  is  important  for  the  protection  of  the  electronic 
components  of  the  PLBS  system  that  some  provisions  for  mounting  and 
protection  are  made.  For  this  reason,  PLBS  shall  be  outfitted  with 
a  complete  set  of  computer  station  housings  which  will  double  as 
workstations  for  the  systems  users.  To  fullfill  this  requirement 
the  workstations  provided  shall  meet  the  following  minimum 
functional  requirements. 

General  Requirements 

Selected  workstations  shall  be  of  a  commercially  available 
variety  which  will  withstand  heavier  than  normal  use  without 
visable  degradation  in  appearance. 

Workstations  shall  be  configured  in  such  a  fashion  as  to  place 
components  out  of  easy  reach  of  unauthorized  personnel  while 
leaving  access  for  assigned  operator (s). 

Electronic  components  shall  be  mounted  in  a  neat  and 
attractive  fashion,  with  all  cables  bundled  and  marked,  switches 
and  controls  clearly  visable  and  all  visable  surfaces  of  a 
non-marring  washable  material  such  as  Formica®. 

Cabinets  and  work  surfaces  shall  be  of  a  substance  that  will 
not  generate  static  electricity  and  will  protect  against  static 
discharge  which  could  damage  electronic  components  of  the  system. 

Mounting  for  the  color  monitors  at  all  stations  shall  be  via  a 
pintle  type  bracket  which  permits  repositioning  in  any  horizontal 
position.  A  horizontally  articulated  arm  with  an  attached  platform 
for  the  monitor  is  preferred. 

Station  cabinetry  and  equipment  shall  be  two  man  portable  with 
all  electronic  components  removed.  If  components  are  not  removable, 
durable  casters  with  a  lock-down  feature  must  be  provided. 

Controller  Station 

Mounting  for  the  following  minimum  equipment  shall  be 
provided : 

One  IBM  PC/AT  microcomputer  with  2  monitors  and  a  keyboard. 

A  video  disc  player. 

A  dot  matrix  printer  with  paper  tray. 

A  communications  system  control  panel. 


One  or  more  I/O  devices  (Mouse,  Joystick,  Keyport  Keypad, 
etc .  )  . 

One  or  more  cassette  tape  audio  recording  machines. 

Sufficient  work  top  space  to  permit  recording  of  comments  and 
related  manual  tasks  shall  be  provided. 

OP FOR  Station 

Mounting  for  the  following  minimum  equipment  shall  be 
provided : 

One  IBM  PC/AT  microcomputer  with  two  monitors  and  a 
keyboard . 

A  video  disc  player. 

A  communications  system  user  panel. 

One  or  more  I/O  devices  (Mouse,  Joystick,  Keyport  Keypad, 
etc . ) . 

Sufficient  worktop  space  for  manual  tasks  shall  be 
provided . 

TC  Stations  (4) 

Mounting  for  the  following  minimum  equipment  shall  be 
provided : 

One  IBM  PC/AT  microcomputer  with  one  color  monitor. 

A  video  disc  player. 

Three  I/O  devices  (Two  Joysticks,  One  Keyport  Keypad) . 

Sufficient  worktop  space  to  permit  use  of  a  tactical  map  and 
minimal  manual  tasks  shall  be  provided. 

Sufficient  leg  and  arm  space  to  permit  two  players  to  be 
situated  comfortably  around  one  color  monitor  shall  be  provided. 

A  facility  shall  be  provided  to  mount  two  C-2298 
communications  control  boxes.  Mounting  shall  be  such  that  the  user 
has  easy  access  to  connect  his  helmet  and  operate  the  control 
switches . 

Figure  4  depicts  two  alternatives  for  the  TC  workstations. 
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SEPARATED  ALTERNATIVE 


One  Player  Mode 

SIDE  -  BY  -  SIDE  ALTERNATIVE 


One  Player  Mode 


FIGURE  4.  Trainee  Workstation  Alternatives 


63 


